Currently, most txnNumber errors refer only to transactions, even if the error pertains to a retryable write. This can create a poor user experience for someone who is only using retryable writes.
We should audit these types of errors on the server and determine whether the command was a part of a retryable write or a transaction. Depending on the answer, we can return one of the following errors:
"Cannot start transaction X on session <UUID> because a newer transaction or retryable write with txnNumber Y has already started on this session."
"Retryable write with txnNumber X is prohibited on session <UUID> because a newer transaction or retryable write with txnNumber Y has already started on this session."
Code that reproduces the issue:
When running above code I'm getting the exception:
MongoCommandException: Command update failed: Cannot start transaction 1 on session c4fd4081-e0f0-40d6-84fc-cdfeccc74e3b - hf9LJrhq2lfp667gnURrBVE7MCUS1NJZYDmWlqfKWl0= because a newer transaction 3 has already started..
This is misleading as there's no explicit transaction in progress.
I know now that we should use either
- ReplaceOneAsync overload without session
- Create new session per call to ReplaceOneAsync with session
background: I've encountered that issue in production code where one method is being used with and without transaction - our solution was to simply create a intermediate overloaded method that creates a session for you and passes it into method that accepts the session.