After the auto-update to source-mssql v4.3.4 (Feb 17), all our CDC connections to an Azure SQL Database geo-replica are failing with "Saved offset no longer present on the server." This worked for months on ≤v4.3.3.

This is a known regression in

source-mssql

v4.3.4 affecting CDC on Azure SQL Database geo‑replicas. From the issue you’re describing (same error text, same timing after Feb 17 auto‑update), the problem is the new LSN validation logic introduced in v4.3.4: the connector now validates the saved/obtained LSN against the SQL Server transaction log range. On Azure SQL geo‑replicas, the platform aggressively truncates the log (

log_reuse_wait_desc = NOTHING

), so: • The connector obtains a fresh LSN. • Between obtaining and validating it, Azure has already recycled the relevant VLFs. • The validation then fails with:

Saved offset no longer present on the server

and suggests increasing log retention / sync frequency. [MSSQL regression issue] This explains why: • All connections that had worked for months on ≤4.3.3 started failing immediately after the v4.3.4 rollout, with no infra/config changes. [MSSQL regression issue] • Even brand‑new connections (no prior state) fail: the new starting LSN itself expires before the connector can complete validation. [MSSQL regression issue] • Changing “Invalid CDC Position Behavior” between Fail sync and Re‑sync data doesn’t help: ◦ Fail sync →

ConfigErrorException

and stops. ◦ Re‑sync data →

TransientErrorException

, resets to current position, but that new position also expires, causing an infinite retry loop. [MSSQL regression issue] The issue is being tracked internally by Airbyte engineering. [MSSQL regression issue] What you can do right now (based on the available info) • There is no documented configuration change on your side that reliably fixes this for Azure SQL geo‑replicas; attempts like increasing DB tier, max storage, forcing log growth, or holding open transactions have been reported as ineffective because Azure still truncates the log aggressively. [MSSQL regression issue] • The knowledge sources do not document a way, on Airbyte Cloud, to pin or roll back the MSSQL source to v4.3.3; the user in the issue explicitly asks if this is possible, but no solution is provided in the shared context. [MSSQL regression issue] Given the limitations of the current information: • If you’re on Airbyte Cloud, the recommended next step is to open a support ticket referencing this regression so they can advise on rollback/workarounds specific to your account. • If you’re on OSS / self‑hosted, the knowledge sources don’t include explicit rollback instructions for this connector version, so I can’t provide a reliable procedure here. In summary: your symptoms match a confirmed regression in v4.3.4’s LSN validation on Azure SQL geo‑replicas, and the shared sources do not yet contain a definitive workaround other than engaging Airbyte support and/or waiting for a connector fix. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

Interesting, it is me who created that issue on GitHub i.e., https://github.com/airbytehq/airbyte/issues/73706