-
Type:
Bug
-
Resolution: Won't Fix
-
Priority:
Minor - P4
-
None
-
Affects Version/s: None
-
Component/s: None
-
Labels:None
-
ALL
3.6 mongos does not validate readConcern.level on find/aggregate commands when the database does not exist. For example:
MongoDB Enterprise mongos> db.serverBuildInfo()['version'] 3.6.23 MongoDB Enterprise mongos> db.getSiblingDB('doesnotexist').runCommand({'find': 'test', readConcern: {level: 'snapshot'}}) { "cursor" : { "firstBatch" : [ ], "id" : NumberLong(0), "ns" : "doesnotexist.test" }, "ok" : 1 } MongoDB Enterprise mongos> db.getSiblingDB('doesnotexist').runCommand({'aggregate': 'test', pipeline: [], cursor: {}, readConcern: {level: 'snapshot'}}) { "result" : [ ], "cursor" : { "id" : NumberLong(0), "ns" : "doesnotexist.test", "firstBatch" : [ ] }, "ok" : 1 } MongoDB Enterprise mongos>
The expected behavior is to reject the command when the readConcern.level is unknown/unsupported. This is the behavior when the collection (or database) does exist:
MongoDB Enterprise mongos> db.test.insertOne({})
{
"acknowledged" : true,
"insertedId" : ObjectId("60da56a21d4ac4b14353e654")
}
MongoDB Enterprise mongos> db.runCommand({'find': 'test', readConcern: {level: 'snapshot'}})
{
"ok" : 0,
"errmsg" : "readConcern.level must be either 'local', 'majority', 'linearizable', or 'available'",
"code" : 9,
"codeName" : "FailedToParse"
}
MongoDB Enterprise mongos> db.runCommand({'aggregate': 'test', pipeline: [], cursor: {}, readConcern: {level: 'snapshot'}})
{
"ok" : 0,
"errmsg" : "readConcern.level must be either 'local', 'majority', 'linearizable', or 'available'",
"code" : 9,
"codeName" : "FailedToParse"
}
Note that 4.0+ clusters do not have this bug.