[SERVER-30090] mongo shell may inject incompatible readConcern when causal consistency is on Created: 11/Jul/17  Updated: 27/Oct/23  Resolved: 24/May/19

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

Type: Bug Priority: Major - P3
Reporter: Misha Tyulenev Assignee: Misha Tyulenev
Resolution: Gone away Votes: 0
Labels: PM-221
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Sprint: Sharding 2017-08-21
Participants:

 Description   

There could be a conflict between afterClusterTime readConcern injected by shell or driver and internal checks if user wants to specify afterOpTime or different readConcern.
The shell code does not overwrite existsing attributes but does not check for invalid combinations either:
https://github.com/mongodb/mongo/blob/r3.5.11/src/mongo/shell/mongo.js#L158-L163

1. A message can not have both afterClusterTime and afterOpTime - it will cause an error.
The check is done here: https://github.com/mongodb/mongo/blob/r3.5.11/src/mongo/db/repl/read_concern_args.cpp#L162-L167
which causes an error at some tests.

2. A message can not have linearizable readConcern:
https://github.com/mongodb/mongo/blob/r3.5.11/src/mongo/db/repl/read_concern_args.cpp#L169-L178
also breaks tests

3. If clusterTime gets to the new unsharded cluster it may hit this error:
https://github.com/mongodb/mongo/blob/r3.5.11/src/mongo/rpc/metadata.cpp#L107-L112



 Comments   
Comment by Misha Tyulenev [ 22/Aug/17 ]

Re #2 it will not hurt to remove it - will do.

Re #3 , sorry missed the question when it was posted, but Andy clarified.
there are several scenarios when mongo shell start talking to another session /connection and this causes all sorts of troubles. This will be settled once we have an agreement on drivers spec. Currently Mongo object does hold the current operationTime (https://github.com/mongodb/mongo/blob/master/src/mongo/shell/mongo.js#L138)

Comment by Andy Schwerin [ 22/Aug/17 ]

I believe that #3 is about a signed cluster time reaching a standalone replica set in the "clusterTime" field of a message. Standalone replica sets don't need and don't transmit cluster times, because the replica set primary maintains the true clock. So #3 should only happen when a shell connects to a sharded cluster, and then the same shell connects to a replica set. This is something tests might do but that users probably don't. In any event, I would think that if we attach the cluster time tracking to the Mongo object instead of making it a global variable in the shell, this problem would evaporate, possibly replaced by some other problem?

RE #2, I agree that a user would probably like to be able to set both linearizable and causal. Perhaps we should just remove that check?

Comment by Spencer Brody (Inactive) [ 18/Aug/17 ]

#1 seems fine, afterOpTime read concern was never a public feature anyway.
#2 seems a little bad, I can imagine a user wanting to set causal consistency mode all the time and still be able to occasionally do a linearizable read.
#3 I don't understand - causal consistency mode is supposed to work on unsharded replica sets. If that doesn't work that seems like a major oversight, or am I misunderstanding the issue?

Generated at Thu Feb 08 04:22:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.