[SERVER-58141] 3.6 mongos does not validate readConcern.level on find/aggregate commands when the database does not exist Created: 28/Jun/21  Updated: 30/Jun/21  Resolved: 30/Jun/21

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

Type: Bug Priority: Minor - P4
Reporter: Shane Harvey Assignee: Eric Sedor
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Operating System: ALL
Participants:

 Description   

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.



 Comments   
Comment by Eric Sedor [ 30/Jun/21 ]

This is good to know about but 3.6 reached end of life in April 2021, so we'll close this as Won't Fix.

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