[SERVER-53293] DBClientCursor not properly applying readConcern when passed in as an argument Created: 09/Dec/20  Updated: 06/Dec/22  Resolved: 10/Dec/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 4.9 Required
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Jason Chan Assignee: Backlog - Replication Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-50985 Tenant collection cloner query must u... Closed
Related
related to SERVER-50985 Tenant collection cloner query must u... Closed
related to SERVER-53294 TenantMigrationRecipientService not a... Closed
is related to SERVER-45692 Ensure all internal inter-node comman... Closed
Assigned Teams:
Replication
Participants:

 Description   

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.



 Comments   
Comment by Jason Chan [ 10/Dec/20 ]

This fix will be addressed as part of SERVER-50985

Comment by Jason Chan [ 09/Dec/20 ]

From SERVER-45692:

The approach will be to add a uassert/fassert (or possibly fassert when enableTestCommands, else uassert) if mongod receives an incoming command, on an internalClient connection, that accepts RWC, but doesn't have it explicitly specified. The reason is that without it being explicitly specified, this internal command would have the user-defined CWRWC default applied to it, which may not give the desired semantics. This will also ensure that future inter-node communication includes explicit RWC as appropriate (because otherwise tests will fail).

This explains that we want an explicit readConcern to be passed from internal clients (but not DBDirectClient, which is why we have the invariant described). This leads me to believe this is actually a bug that we are unable to pass in a non-empty readconcern to DBClientConnection calls that use DBClientCursor.

Comment by Jason Chan [ 09/Dec/20 ]

Adding an invariant will also serve as an audit of our code for places where we might not be using the readConcern that we expect when making DBClient calls.

Generated at Thu Feb 08 05:30:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.