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."

ORIGINAL POST:

Code that reproduces the issue:

        private static async Task TestSingleSession(MongoClient client)
        {
            var col = client.GetDatabase("_test").GetCollection<BsonDocument>("concurrent");                        
            using (var session = await client.StartSessionAsync())
            {
                var ops = Enumerable.Range(0, 100)
                    .Select(async e =>
                    {
                        await col.ReplaceOneAsync(session, Builders<BsonDocument>.Filter.Eq("_id", e),
                            new BsonDocument
                            {
                                { "_id", e },
                                { "data", $"someData_{e}" },
                            },
                            new UpdateOptions { IsUpsert = true });
                    })
                    .ToArray();
                await Task.WhenAll(ops);
            }
        }

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.