-
Type:
Task
-
Resolution: Done
-
Priority:
Minor - P4
-
Affects Version/s: None
-
Component/s: Sharding
-
Sharding 2021-09-20
-
37
-
None
-
0
-
None
-
None
-
None
-
None
-
None
-
None
A mongod process won't reject an explicit {readConcern: {}} object even when it is not the first statement within a multi-statement transaction. The {readConcern: {}} object has no practical effect and won't lead the request to do any additional waiting. (Note also that an empty readConcern object overrides the cluster-wide readConcern value.)
A mongos process is therefore safe to propagate the explicit {readConcern: {}} object and so this dassert() in TransactionRouter should be adjusted to avoid false positives in testing.
// The first command sent to a participant must start a transaction, unless it is a transaction // command, which don't support the options that start transactions, i.e. startTransaction and // readConcern. Otherwise the command must not have a read concern. auto cmdName = cmd.firstElement().fieldNameStringData(); bool mustStartTransaction = isFirstStatementInThisParticipant && !isTransactionCommand(cmdName); if (!mustStartTransaction) { dassert(!cmd.hasField(repl::ReadConcernArgs::kReadConcernFieldName)); }