-
Type:
Task
-
Resolution: Done
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Testing Infrastructure
-
None
-
Fully Compatible
-
TIG 2017-03-06
-
0
There is a case where the "listCollections" command can return two info objects for the same namespace if a client writes directly to the system.views collection. This scenario causes ReplSetTest's checkDBHashesForReplSet() function to throw an error because it'll find the options differ when comparing the options of the "test.myns" collection to the "test.myns" view. Adding the clause && secondaryInfo.type === primaryInfo.type to this line and throwing an error if no match for the (name, type) combination is found allows the data consistency checks we perform after running our tests to tolerate this scenario.
Credit to robert.guo for this idea as opposed to removing the ability for the fuzzer to write directly to the system.views collection.
assert.commandWorked(db.runCommand({create: "myns"}));
assert.writeOK(db.system.views.insert({
_id: db.getName() + ".view",
viewOn: "coll",
pipeline: [],
}));
printjson(db.getCollectionInfos());
Output
[
{
"name" : "myns",
"type" : "collection",
"options" : {
},
"info" : {
"readOnly" : false
},
"idIndex" : {
"v" : 2,
"key" : {
"_id" : 1
},
"name" : "_id_",
"ns" : "test.myns"
}
},
{
"name" : "myns",
"type" : "view",
"options" : {
"viewOn" : "coll",
"pipeline" : [ ]
},
"info" : {
"readOnly" : true
}
},
{
"name" : "system.views",
"type" : "collection",
"options" : {
},
"info" : {
"readOnly" : false
},
"idIndex" : {
"v" : 2,
"key" : {
"_id" : 1
},
"name" : "_id_",
"ns" : "test.system.views"
}
}
]
- is related to
-
SERVER-28065 blacklist jstests/core/views/duplicate_ns.js from initial sync suites
-
- Closed
-