Details
-
Bug
-
Resolution: Fixed
-
Major - P3
-
None
-
None
-
Fully Compatible
-
ALL
-
v5.1, v5.0, v4.4, v4.2
-
Sharding 2021-10-18
Description
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).
Attachments
Issue Links
- is duplicated by
-
SERVER-47915 Write commands silently ignore readConcern via mongos
-
- Closed
-
- related to
-
SERVER-37523 Call supportsReadConcern for all commands in mongos
-
- Backlog
-