[SERVER-30822] Update does not give an error message when $setOnInsert fails on FCV 3.6 Created: 24/Aug/17  Updated: 27/Oct/23  Resolved: 05/Sep/17

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

Type: Bug Priority: Major - P3
Reporter: Kimberly Hou Assignee: Backlog - Query Team (Inactive)
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

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 })

Participants:

 Description   

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 <find> 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.



 Comments   
Comment by Ian Whalen (Inactive) [ 05/Sep/17 ]

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.

Comment by Tess Avitabile (Inactive) [ 25/Aug/17 ]

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.

Generated at Thu Feb 08 04:25:07 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.