Source MSSQL: datetime fields with millisecond precision are being rounded down to the second, causing rows to keep incrementally syncing when they shouldn't and replicating incorrect precision to destination #10262
Labels
area/connectors
Connector related issues
area/databases
community
connectors/destination/mssql
frozen
Not being actively worked on
team/db-dw-sources
Backlog for Database and Data Warehouse Sources team
type/bug
Something isn't working
Environment
Current Behaviour
Initial load completes as expected (all rows replicated). However, running a subsequent load (with the incremental + append option, using ModifiedDate (datetime) as a cursor field), all records are loaded again even though there are no changes in the source MSSQL database cursor field.
In the source database (a standard AdventureWorks SQL Server demo database), all the ModifiedDate values in the Sales.Customer table are set to "2014-09-12 11:15:07.263". When syncing this data, Airbyte saves the cursor value rounded down to "2014-09-12 11:15:07Z", stripping out the millisecond component. The next time a sync runs, of course 2014-09-12 11:15:07.263 is technically greater than 2014-09-12 11:15:07Z, so all records are synced over again when they shouldn't be.
Interestingly, the record payload itself within Snowflake is also rounded, meaning that both the cursor and the replicated data have less precision than the source database:
SQL Server:
Snowflake:
Expected Behaviour
No changes to the cursor value in the source should yield no records emitted; replicated columns should contain the same precision as the source
Logs
logs-4.txt
logs-5.txt
I've also tried to point out useful bits below with line numbers
Log highlights
Initial sync (logs-4.txt), the cursor is null - therefore replicate everything (expected)However, in the incremental run (logs-5.txt), shenanigans ensue:
Steps to Reproduce
Are you willing to submit a PR?
Willing, but perhaps not all that able! :) I'm not super familiar with the Airbyte codebase, so it may be more efficient for someone else to look into it who knows it better.
This issue looks broadly pretty similar to existing issues #8904 and #9915, but wanted to call out that MSSQL is also affected.
The text was updated successfully, but these errors were encountered: