Transaction rollbacks

[SvdSinner]

There are two issues with how transactions rollback currently in Sql Server (might be relevant to other databases, don't know):

1. The rollback command uses the same timeout as normal commands. However, for a large synchronization, the transaction might include dozens, hundreds or thousands of sql commands. Rolling a large transaction back takes significantly more time to complete that any of the individual sql commands it is rolling back. This means that rolling back large transactions will almost always result in a connection timeout error. Rollback commands should always be executed with a CommandTimeout of 0 (no limit).
2. When the connection timeouts occur, all knowledge of the original error/exception that triggered the roll back is lost, and nothing meaningful is able to be logged. Any SqlExceptions thrown while rolling back (timeout or otherwise) need to include information on why the rollback that failed was occurring. This could be done as inner exceptions or by a custom exception that includes the additional information. Without this, long syncs fail with no indication of what went wrong, just that some unknown thing triggered rollback and that the rollback caused a timeout error.

[Mimetis]

Did you tried and look at the last version? (v0.9.8) that has been merged yesterday in main?

Timeout & Deadlocks are defined as transient errors.
That means that the transaction will be run again each time a transient error is happenning.

If you want to reduce the size of transactions, you can opt in for options.TransactionMode = TransactionMode.PerBatch; that will reduce the size of the transactions.

Regarding the errors, I think with the last version published, the error is raised correctly, but not sure honestly.
Do you have an example ?

[SvdSinner]

I'll sync my fork with the newest and re-test. The way to replicate is to sync a table with a foreign key reference to a table that isn't synced and thereby causing "The MERGE statement conflicted with the FOREIGN KEY constraint "FK_BlahBlahBlah". The conflict occurred in database "someDb", table "dbo.thisTable", column 'thisColumn'."