-
Type: Improvement
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: 4.9 Required
-
Component/s: None
-
None
-
Replication
We use DBClientCursor to facilitate many of the calls supported by the DBClientBase interface (eg. DBClientBase::query). DBClientCursor accepts a readConcernObj as an optional argument. However, the readConcernObj passed in will always be overwritten to be empty due to the following:
1. As part of initiating the DBClientCursor object, we use the legacy parsing code supplied by QueryRequest.
2. This calls QueryRequest::init with fromQueryMessage always set to true.
3. We will always initialize the query message with an empty readConcern.
4. When trying to parse the QueryRequest as a findCommand, we will always have a readConcern field with an empty value.
5. The parsed cmd will always have a readConcern field (but the value itself will always be empty) so we never actually enter this conditional to append the passed in readConcernObj.
Since we use DBClientCursor for many of our DBClientConnection and DBDirectClient calls, having a readConcern field that doesn't actually append the readConcern is very misleading. Instead we should add an invariant to ensure that no readConcernObj is passed into DBClientCursor. We should also investigate whether the optional argument can be removed altogether.
We already have a similar invariant for DBDirectClient::query but we should probably move it further down the chain to avoid confusion.
- is duplicated by
-
SERVER-50985 Tenant collection cloner query must use readConcern majority
- Closed
- is related to
-
SERVER-45692 Ensure all internal inter-node commands which accept read/write concern explicitly specify it
- Closed
- related to
-
SERVER-50985 Tenant collection cloner query must use readConcern majority
- Closed
-
SERVER-53294 TenantMigrationRecipientService not actually using majority read concern
- Closed