The knowledge sources explain how Incremental | Append + Deduped is supposed to work, but they do not describe a situation where an incremental sync “runs forever” or repeatedly retries, nor do they list any specific bug for SQL Server → Snowflake that would cause this behavior. Because of that, I can’t point to a documented root cause for your exact issue. From the docs, the main things that can block or stall incremental syncs are related to the cursor field and how deltas are queried: - Incremental sources use a query like:

sql   SELECT *    FROM table    WHERE cursor_field > 'last_sync_max_cursor_field_value'

for Incremental + Deduped. [[Inc deduped limits](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes/incremental-append-deduped#known-limitations)] - If the cursor field is not updated correctly in the source, or if it stops increasing, the connector may not see any “new” rows and can behave unexpectedly. [[Inc deduped limits](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes/incremental-append-deduped#known-limitations)] - For Incremental (Append), the pattern is similar, using

>=

instead of `>`: [[Inc append limits](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes/incremental-append#known-limitations)]

sql   SELECT *    FROM table    WHERE cursor_field >= 'last_sync_max_cursor_field_value'

The Snowflake source docs (as an example of incremental behavior) also emphasize that the cursor field must be: - Monotonically increasing, - Not updated after creation, - Without many duplicates or NULLs. [[Snowflake incremental](https://docs.airbyte.com/integrations/sources/snowflake#incremental-sync)] These same principles apply conceptually to other sources: if the cursor field is problematic, incremental sync can misbehave. However, the provided documentation does not say that a bad cursor or primary key configuration will cause the job to “run forever” or loop with multiple attempts; it only states that updated records might not be picked up or that intermediate changes can be missed. [[Inc deduped limits](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes/incremental-append-deduped#known-limitations); [Inc append limits](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes/incremental-append#known-limitations)] So, based solely on the docs: - I can confirm that Incremental | Append + Deduped depends heavily on a correct cursor field and primary key configuration, and misconfiguration can cause data not to be replicated. [[Incremental deduped](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes/incremental-append-deduped)] - I cannot confirm from the knowledge sources why your incremental job is “running forever” or retrying; there is no explicit mention of this symptom or a fix for it. Given these limits, the only doc-based checks I can suggest are: 1. Verify that each affected stream has: - A valid cursor field that still exists in SQL Server and is being updated/monotonically increasing. - A correct primary key so deduplication can complete. [[Incremental deduped](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes/incremental-append-deduped)] 2. Confirm that the source really has new/updated rows whose cursor value is greater than the last stored cursor value, otherwise the incremental query may not return anything. [[Inc deduped limits](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes/incremental-append-deduped#known-limitations)] 3. If Full Refresh | Overwrite + Deduped completes but Incremental keeps running, collect logs and configuration details and escalate via Airbyte’s support channels, because this “runs forever” behavior is not documented in the provided sources. If you can share the configured cursor field and primary key for one problematic stream, I can map that against the documented expectations, but I still won’t be able to confirm any undocumented bugs or performance issues beyond what the docs state.

The knowledge sources do not state that the SQL Server (MSSQL) source connector was upgraded in a way that removes or disallows Incremental | Append + Deduped. What the docs do say is: - Sync modes are a combination of source and destination capabilities. Incremental vs Full Refresh is about how the source reads; Append / Append + Deduped / Overwrite are about how the destination writes. [[Sync modes overview](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes)] - Append + Deduped is described as a supported mode in general, when both source and destination support the required capabilities (incremental + primary key). [[Incremental deduped](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes/incremental-append-deduped); [Sync modes overview](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes)] There is no mention in the provided MSSQL migration guide of removing incremental support or changing which sync modes are allowed; it only documents changes like data type mappings and CDC cursor behavior. [[MSSQL migration guide](https://docs.airbyte.com/integrations/sources/mssql-migrations)] So, based on the available docs: - I cannot find any evidence that a recent SQL Server source upgrade removed support for Incremental | Append + Deduped. - Whether that mode appears for a given stream still depends on the combination of: - The source supporting Incremental for that stream, and - The destination (Snowflake) supporting Append + Deduped for that stream. [[Sync modes overview](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes)] If the mode has disappeared or behaves differently after an upgrade, that behavior is not documented in the sources you provided, so I can’t confirm it from documentation alone.