Mongos does not validate readConcern on insert/update/delete commands

XMLWordPrintableJSON

    • Fully Compatible
    • ALL
    • v5.1, v5.0, v4.4, v4.2
    • Sharding 2021-10-18
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      Mongos does not validate readConcern on insert/update/delete commands:

      MongoDB Enterprise mongos> db.serverBuildInfo()['version']
5.0.0-rc4
MongoDB Enterprise mongos> db.runCommand({'update': 'test', updates: [{q:{}, u:{'$set': {x:1}}}], readConcern: {level: 'snapshot'}})
{
	"nModified" : 0,
	"n" : 0,
	"ok" : 1
}
MongoDB Enterprise mongos> db.runCommand({'insert': 'test', documents: [{}], readConcern: {level: 'snapshot'}})
{
	"n" : 1,
	"ok" : 1
}
MongoDB Enterprise mongos> db.runCommand({'delete': 'test', deletes: [{q:{}, limit: 1}], readConcern: {level: 'snapshot'}})
{
	"n" : 1,
	"ok" : 1
}

      The same commands on mongod result in an error:

      PRIMARY> db.runCommand({'insert': 'test', documents: [{}], readConcern: {level: 'snapshot'}})
{
	"ok" : 0,
	"errmsg" : "Command insert does not support { readConcern: { level: \"snapshot\", provenance: \"clientSupplied\" } } :: caused by :: read concern not supported",
	"code" : 72,
	"codeName" : "InvalidOptions"
}

      Now you might say "sure, why would it validate readConcern on a write command?" Well, drivers expose snapshot reads support through the sessions api. You can declare a session with "snapshot=True" and then all operations using that session follow the snapshot reads protocol, eg:

      # All operations read from the same snapshot.
with client.start_session(snapshot=True) as session:
    # sends readConcern.level=snapshot, the session records atClusterTime response
    docs1 = list(coll1.find({}, session=session))
    # sends readConcern.level=snapshot plus atClusterTime
    docs2 =  list(coll2.aggregate([], session=session))
    # sends readConcern.level=snapshot plus atClusterTime
    values = coll3.distinct('field', session=session)

      Drivers would like any operation that doesn't support readConcern.level=snapshot to error. For example, write commands (insert, update, delete, findAndModify, etc) and unsupported read operations like listCollections should error. The plan is to send readConcern.level snapshot with all commands in a snapshot session and rely on the server to report an error when that particular command is not supported. This plan only works if Mongos consistently validates readConcern on all commands (like mongod).

            Assignee:
            Jonathan Lee
            Reporter:
            Shane Harvey
            Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: