-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Unknown
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
The transaction path in CreateType0Section uses AddIfNotAlreadyAdded for readConcern, which silently drops the transaction's readConcern if the command already has one (e.g. via CreateCommand). Ideally it should use extraElements.Add() like the snapshot path, so the transaction's readConcern always wins. It doesn't hit any errors today because GetReadConcernForCommand returns null for IsInTransaction and there's a separate GetReadConcernForFirstCommandInTransaction, but a raw RunCommand with an explicit readConcern inside a transaction would get the wrong precedence.
Repro:
using var session = client.StartSession(); session.StartTransaction(new TransactionOptions( readConcern: ReadConcern.Majority, writeConcern: WriteConcern.WMajority)); var command = new BsonDocument { { "find", "txn_readconcern_test" }, { "readConcern", new BsonDocument("level", "local") } }; database.RunCommand<BsonDocument>(session, command); session.CommitTransaction(); var findEvent = eventCapturer.Events.OfType<CommandStartedEvent>().First(); var sentReadConcern = findEvent.Command["readConcern"].AsBsonDocument; // This assertion fails (it sends "local" instead of "majority") sentReadConcern["level"].AsString.Should().Be("majority");
- is blocked by
-
CSHARP-5468 Change handling of Read/WriteConcern in scope of transaction to be spec compliant
-
- Backlog
-
- is related to
-
CSHARP-5740 Duplicate read concern error
-
- In Code Review
-