OPERATIONAL DEFECT DATABASE
...
...
After setting FCV to 3.6 on 3.5.12, the mongo shell session appears as from the repro. This is different from FCV 3.4, which would give the following response: WriteResult({ "nMatched" : 0, "nUpserted" : 0, "nModified" : 0, "writeError" : { "code" : 16837, "errmsg" : "cannot use the part (a of a.b) to traverse the element ({a: 1.0})" } }) In the example, field 'a' can actually be nearly any data type including a number, a string, an array, NaN, null, or undefined. This difference can also be observed regardless of whether multi or upsert is set to true / false. FCV 3.6 would return nMatched as the number of documents matching the portion of the query. The WriteResult given in FCV 3.6 may not accurately reflect a reason (or reflect a reason at all) for why no documents were upserted / modified, especially when upsert is set to true.
ian@10gen.com commented on Tue, 5 Sep 2017 14:51:43 +0000: Per Tess' comment above this was a bug in 3.4 which was fixed in 3.6 and we are not backporting the fix to 3.4. tess.avitabile commented on Fri, 25 Aug 2017 15:44:26 +0000: This is a bug on 3.4 and 3.6 featureCompatibilityVersion 3.4. We call prepare() on the ModifierInterface for $setOnInsert even in an update context, when we will not apply it. Then if there is a blocking element and the $setOnInsert cannot be applied, we return an error, even though we were not going to apply the $setOnInsert. On 3.4. On 3.6 featureCompatibilityVersion 3.4.
FCV 3.6: > db.fuzzer.insert({'a': 1 }) WriteResult({ "nInserted" : 1 }) > db.fuzzer.update({}, {$setOnInsert: {'a.b': 2 }}) WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 0 })
MongoDB Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.
