We are running the latest Airbyte 2.2.* and we hav...
# replication-ask-ai
r
We are running the latest Airbyte 2.2.* and we have suddenly started getting a 403 error whenever we try to change the selected tables in our connections with a postgres source. The errror message detail says "Catalog does not belong to the specified connection's source". This is happening for all our connections, not just one or two.
k
Thinking completed I am sorry, but the provided knowledge sources do not contain specific information or documented root causes for the error
"Catalog does not belong to the specified connection's source"
accompanied by a 403 status code when changing selected tables on Airbyte 2.2.*. However, based on how Airbyte manages connections and catalogs internally: • Source and Catalog Association: In Airbyte's architecture, each source actor discovers and generates an actor catalog (
actor_catalog
/
actor_catalog_fetch_event
), which is then associated with the configured connection catalog and the specific source (
source_id
) [Config Database; actor_catalog_fetch_event]. The error indicates that the platform's backend validation detects a mismatch between the catalog ID/version being submitted in the request and the catalog registered for that connection's
source_id
. • Schema Refresh / Outdated State: When source definitions or versions change, UI sessions can hold stale catalog references. A common recommendation in Airbyte when schema or catalog sync updates fail is to run a manual schema discovery/refresh on the source or within the connection's Schema tab to regenerate and associate the latest catalog before saving stream selections [Schema refresh does not leave a clear way to apply removed-stream changes]. If refreshing the schema from the UI does not resolve it, this may be a regression in validation or an issue with user/workspace permissions in version 2.2.*, and it is recommended to open an issue on the Airbyte GitHub repository. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
r
@kapa.ai I can't refresh or change the schema because it's reporting a breaking change in the schema and I get the 403 when trying to load the diff for that chance. The UI was freshly opened, so the UI state is not out of date unless airbyte-server caches things and the cache is stale.
k
Thinking completed I am sorry, but the provided knowledge sources do not contain specific information or a documented resolution for the 403 error occurring when loading a schema diff for a breaking change, nor do they detail the caching behavior of
airbyte-server
in this specific scenario. Based on related knowledge: • Breaking Changes and Catalog Mismatches: Airbyte tracks breaking changes at the actor definition level (e.g., via
actor_definition_breaking_change
) [actor_definition_breaking_change]. When a breaking change is reported, the platform attempts to compare the stored configured catalog against the freshly discovered source catalog [Schema refresh does not leave a clear way to apply removed-stream changes]. • The "Catalog does not belong to..." Failure: The backend validates that the catalog identifier referenced in the request matches the
source_id
associated with that connection. If loading the diff fails with a 403 before you can apply changes, the server's API call to generate or fetch the catalog diff is failing this ownership/authorization check on the backend. Because the knowledge sources do not provide a fix for this deadlock, consider the following potential paths: 1. Check Airbyte Server Logs: Inspect the
airbyte-server
container logs at the time the 403 is thrown to find the exact endpoint returning the failure and inspect whether it is an authorization issue (e.g., workspace permissions) or an internal ID mismatch. 2. Update the Connector Definition/Version: If the breaking change is tied to a connector upgrade, check whether rolling back the connector version or upgrading to a newer patch releases the validation block. 3. Report the Issue: Because this blocks both schema refresh and connection modification across all Postgres connections on your instance, it may be an internal validation regression in your current platform version. You should report this on the Airbyte GitHub repository or reach out via the Airbyte Community Slack. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.