Conflict resolution methods should be handled as transactions

[amertlich]

When a TableOperationError occurs during sync the API supports a few different operations: CancelAndDiscardItemAsync CancelAndUpdateItemAsync and UpdateOperationAsync. These are useful methods but they are not atomic and as such can leave the operation queue in a bad state if something goes wrong with the offline store.

For example in CancelAndDiscardItemAsync (see here) the Operation is FIRST canceled and then Deleted -- but if the deletion fails for some un-forseen reason (like triggers or constraints on the database I probably shouldn't be using 😬) then the operations queue is left in a corrupt state.

Currently I can wrap this all in a transaction myself but then the rollback scenario causes the in memory state of the operation queue to become out of sync. If I could re-initialize the operation queue via a public API that might be easier, because I know making this an atomic may be a bit of a challenge the way the operation queue is separated from the offline store.

[adrianhall]

You can't wrap a transaction across the remote operation and remote database. Too many things can go wrong in that case. Also, you should NOT be adding triggers or contstraints to the operations queue, so we can remove that as a cause. When removing from the operations queue, you should have full permission to do so.

There is a slight risk of the application being shut down forcefully as you do the operation, resulting in the operation being done but the operation queue not being updated. Not a lot I can do here.

I've been thinking of adding a "complete operations queue rebuild" - basically, wipe the operations queue and pull the metadata for every record in the entire table and then do the logic to re-synchronize the local copy. However, the logic to do that is non-obvious and I wanted to do that in the v8 table.

[amertlich]

I don't understand "remote operation and remote database" because the transaction I'm referring to is local. I assume you mean the current architecture doesn't enforce that the operation queue is in the same database as the offline store (so could be considered "locally remote").

We have no triggers/constraints on the operations queue, it's on the table/item the operation is referencing. I understand this is not a supported scenario. I was attempting to discard/replace a referenced item using the the above methods and then handling the exceptions if prevented by the data store -- this was leaving the operations queue in bad state if we needed to correct the item state and then continue the operation, but the operation was now lost.

We've worked around the problem for now, thanks!

[adrianhall]

This will be much easier to do in the new EF Core architecture. Unfortunately, it's relatively difficult to avoid operations queue corruption when you mess with the database structure in the current architecture.