Hi all 👋 Looking for advice on intermittent missing rows with Incremental | Append + Deduped on a SQL Server → Snowflake pipeline. Setup: • Airbyte OSS deployed on AKS via Helm • Source:

airbyte/source-mssql:4.1.22

• Destination:

airbyte/destination-snowflake:3.15.4

• Sync mode: Incremental | Append + Deduped • Frequency: every 15 minutes • Cursor field:

UpdatedDateTime

(SQL Server

DATETIME

, ~3.33 ms precision, stored in UTC) • Primary key:

Id

(BIGINT IDENTITY) • Both SQL Server

UpdatedDateTime

and the Airbyte cluster are UTC, no timezone mismatch Problem: Most rows sync correctly, but occasionally rows are missed entirely — sometimes by 2+ days. The source

UpdatedDateTime

shows the row was updated, but Snowflake (both raw and final tables) never received the new version. Sync jobs themselves complete with

failures: [ ]

and no errors. The cursor advances normally. What I've ruled out: • Not a sync failure — jobs succeed cleanly • Not a timezone issue — both sides are UTC • Not the

UpdatedDateTime

not being maintained — confirmed updated values exist in source • Not a dedup problem — checked the raw table, the new row version was never extracted Hypothesis: Classic transaction visibility skew — long-running transactions stamp

UpdatedDateTime

at UPDATE time but commit later, after the cursor has already advanced past that timestamp. The row becomes permanently invisible to incremental sync because

UpdatedDateTime <= cursor

on subsequent runs. Constraints: • Can't enable CDC right now (need DBA coordination + change window) • Looking for a lookback / overlap window approach but don't see a native option in source-mssql Questions: 1. Has anyone hit this with

source-mssql

+

DATETIME

cursor? Was transaction commit skew the actual cause? 2. Is there a supported way to configure a cursor lookback window I'm missing? 3. For those who've gone the cursor-rewind route (modifying the

state

table directly), any gotchas with recent Airbyte versions? 4. Any other proven mitigations short of CDC? Thanks in advance 🙏

Hypothesis:

Classic transaction visibility skew — long-running transactions stamp

UpdatedDateTime

at UPDATE time but commit later, after the cursor has already advanced past that timestamp. The row becomes permanently invisible to incremental sync because

UpdatedDateTime <= cursor

on subsequent runs.

Hi. We've looked at this potential failure mode in the past and ruled it out because the connector acquires a lock in order to determine the maximum timestamp value. As long as the timestamps are being set by the DB and not an application, this shouldn't be possible.