fix(quarantine): prevent double catalog.schema qualification of quarantine table#110
Merged
Merged
Conversation
…ntine table QuarantineManager derived the quarantine table name from self.target — which BaseTargetDelta has already folded into a fully qualified catalog.schema.table — while also passing quarantineTargetDetails.database. TargetFactory then re-applied the database, producing an over-qualified identifier (e.g. main.schema.main.schema.orders_quarantine) and failing the pipeline with "Table identifier ... supports at most three parts (catalog.schema.table)". When a quarantine database is supplied, derive the suffixed name from the unqualified target so it is qualified exactly once; otherwise reuse the already-qualified target name. Behaviour is unchanged when no quarantine database is supplied (e.g. the feature-samples quarantine_table spec). Bump version to v0.17.2.
1 task
…ne_table spec Add a catalog-qualified `database` to the quarantine_table dataflow's quarantineTargetDetails so the feature-samples suite exercises the supplied- database quarantine path. This is the exact configuration that previously produced an over-qualified table identifier; it now deploys and runs cleanly, guarding against regressions of the double-qualification fix.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
QuarantineManager._init_quarantinebuilt the quarantine table name fromself.target,which
BaseTargetDelta.__post_init__has already folded into a fully qualifiedcatalog.schema.table. It then also passedquarantineTargetDetails.database, soTargetFactory.create(...)re-applied the catalog+schema a second time. When a dataflow setquarantineMode: "table"with a catalog-qualifieddatabase, this produced an over-qualifiedidentifier such as
main.schema.main.schema.orders_quarantine, and the pipeline failed with:Fix
In
src/dataflow/quarantine.py, add conditional handling that detects a supplied quarantinedatabase:database→ derive the suffixed name from the unqualified target(
self.target.split('.')[-1]) so it is qualified exactly once, and pass the database through.database→ reuse the already-qualified target name and leavedatabaseunset.table→ used verbatim (unchanged).No behaviour change when
quarantineTargetDetailsomitsdatabase.Changes
src/dataflow/quarantine.py— quarantine table identifier composition.VERSION—v0.17.1→v0.17.2.Test plan
py_compilepasses; logic verified across all four cases (supplied catalog-qualified db,no db, explicit table, schema-only db) — each resolves to ≤ 3 parts.
_es,main, serverless) — SUCCESS(regression check:
quarantine_tablespec has nodatabase, path unchanged).database)via the tpch_sample silver pipeline, which previously reproduced the failure.
Related