A successful Airbyte MSSQL CDC sync can expose half a transaction

An Airbyte MSSQL CDC issue reports a source transaction that moves rows between two tables, while the destination receives only part of the commit in one sync. The remaining events appear later. The reporter reproduced the behavior on connector versions 4.4.12 and 5.1.2 in issue #90141. A green sync can therefore coexist with a temporary downstream state that never existed in SQL Server.

Identify the invariant the destination must preserve

For the reported move, a row should exist in exactly one of two tables after the source commit. Build a reconciliation query over the replicated keys and run it after each sync, not only after the nightly batch. Record source commit LSN, Airbyte state, emitted record counts, and destination apply time. Separate eventual arrival from permanent loss: the issue says the remaining changes arrived after the source maximum LSN advanced, but that is a reproduction, not a guarantee for every workload.

Keep consumers away from a partial view

If a dashboard, reverse-ETL job, or model acts on both tables, schedule it after a completeness gate or materialize a versioned snapshot only when the invariant passes. A fixed delay is weaker than checking the state itself. Document what “ready” means for the business process: all changes for a commit, all expected keys, and a bounded freshness window. Airbyte's MSSQL source documentation describes CDC and at-least-once delivery, but does not promise transaction-atomic visibility in every destination.

Reproduce before changing connector state

Use a controlled multi-row, multi-table transaction in a test connection with the same connector version and destination mode. Compare consecutive syncs and issue status before upgrading or changing CDC settings. Preserve a state backup and a rollback plan. Do not edit offsets merely to make the next sync look complete; that could create a more serious gap.

Adovo’s view

Replication success is a transport signal. Business readiness is an invariant. If one source commit has meaning across tables, consumers should see it only after the destination can prove that meaning survived.