fix(destination-redshift): use anti-join instead of correlated NOT EXISTS in dedup insert - #83261
fix(destination-redshift): use anti-join instead of correlated NOT EXISTS in dedup insert#83261devin-ai-integration[bot] wants to merge 2 commits into
Conversation
Co-Authored-By: bot_apk <apk@cognition.ai>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
👋 Greetings, Airbyte Team Member!Here are some helpful tips and reminders for your convenience. 💡 Show Tips and TricksPR Slash CommandsAirbyte Maintainers (that's you!) can execute the following slash commands on your PR:
📚 Show Repo GuidanceHelpful Resources
|
Co-Authored-By: bot_apk <apk@cognition.ai>
|
Note Autopilot progressive rollouts are not enabled for the following modified connector(s):
This is a courtesy heads-up only — it does not block merge or fail any check. |
|
Deploy preview for airbyte-docs ready!
Deployed with vercel-action |
|
What
Dedup (
*_deduped) syncs on destination-redshift 4.0.4 fail with:Related to https://github.com/airbytehq/oncall/issues/13202:
The upsert's insert step was:
The
NOT EXISTSsubquery references the outer dedup table, so it is a correlated subquery. Before 4.0.4 the inner predicate was a plain equijoin; #83245 changed it to the NULL-safeORform (to fix https://github.com/airbytehq/oncall/issues/13186), and Redshift's planner appears to reject that correlated shape — the reported failure has an 8-column compound primary key, so the predicate expands to 8 ANDedORgroups. Many other 4.0.4 dedup syncs succeed, which is consistent with the rejection depending on the predicate shape rather than on dedup in general. See AWS: correlated subquery patterns that aren't supported.How
RedshiftSqlGenerator.insertNewRowsnow uses aLEFT JOINanti-join instead of a correlatedNOT EXISTS, keeping the NULL-safe PK semantics from #83245:The anti-join is detected on
_airbyte_raw_id, which is declaredNOT NULLinMETA_COLUMNS— using a PK column for theIS NULLcheck would be ambiguous precisely for the NULL-PK rows this predicate exists to handle. Columns in theSELECTlist are now qualified with the dedup table so the join can't make them ambiguous.NOT EXISTSand the anti-join match the same set of rows, and since non-matching rows contribute exactly one all-NULL right side, the join cannot duplicate inserted rows.Not addressed here:
updateExistingRowsstill matches PKs with plain=(Redshift requires a pure equijoin inUPDATE ... FROM), so rows whose PK contains NULL are still never UPDATEd — the https://github.com/airbytehq/oncall/issues/13186 class of bug may only be half-fixed. That is pre-existing behavior from #83245 and would need a different formulation (e.g. delete+insert, or a NOT NULL PK-signature column); calling it out rather than expanding scope on a customer-impacting regression fix.Review guide
airbyte-integrations/connectors/destination-redshift/src/main/kotlin/io/airbyte/integrations/destination/redshift/sql/RedshiftSqlGenerator.kt—insertNewRowsrewriteairbyte-integrations/connectors/destination-redshift/src/test/kotlin/io/airbyte/integrations/destination/redshift/sql/RedshiftSqlGeneratorTest.kt— asserts no correlatedNOT EXISTS, the anti-join shape, and NULL-safe matching for single and compound PKsmetadata.yaml/docs/integrations/destinations/redshift.md— 4.0.4 → 4.0.5 + changelogTest Coverage
./gradlew :airbyte-integrations:connectors:destination-redshift:testpasses locally. The new/updated unit tests assert the absence of the correlatedNOT EXISTSand the presence of the anti-join with NULL-safe compound-PK matching, so they fail against the 4.0.4 statement shape. The change has not been validated against a live Redshift cluster in this session — integration tests / a pre-release validation on the affected connection would be the confirming evidence.Breaking Change Evaluation
Not breaking: no schema, spec, state, PK, cursor, or stream changes — only the SQL shape of the dedup insert. Non-breaking PATCH bump to 4.0.5. Progressive rollout is not enabled for this connector, so no
-rc.xsuffix.User Impact
Dedup syncs to Redshift that failed on 4.0.4 with the correlated-subquery error should succeed again, with the NULL-safe PK matching from 4.0.4 preserved. Users currently blocked can pin destination-redshift to 4.0.3 as a workaround until 4.0.5 is released, at the cost of re-introducing the duplicate-rows behavior for NULL PK values described in oncall 13186.
Can this PR be safely reverted and rolled back?
Link to Devin session: https://app.devin.ai/sessions/b5ce5067355f491499b1f69e110bd765