[SERVER-30803] $mul on a numeric type results in inaccurate error message on FCV 3.6 Created: 23/Aug/17  Updated: 30/Oct/23  Resolved: 12/Sep/17

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 3.5.11
Fix Version/s: 3.6.0-rc0

Type: Bug Priority: Major - P3
Reporter: Kimberly Hou Assignee: Justin Seyster
Resolution: Fixed Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

db.fuzzer.insert({ a:1, b: NumberLong(-9223372036854776000) })
db.fuzzer.update({a:1}, {$mul: {b: NumberLong(2)}})

Sprint: Query 2017-10-02
Participants:

 Description   

After setting FCV to 3.6, the response received from the repro is as follows:

WriteResult({
	"nMatched" : 0,
	"nUpserted" : 0,
	"nModified" : 0,
	"writeError" : {
		"code" : 12,
		"errmsg" : "Don't know how to handle unexpected SafeNum type"
	}
})

The message given is vague and likely should not be reflected externally.



 Comments   
Comment by Ramon Fernandez Marina [ 12/Sep/17 ]

Author:

{'username': u'jseyster', 'name': u'Justin Seyster', 'email': u'justin.seyster@mongodb.com'}

Message:SERVER-30803 Better error message for invalid result with $inc/$mul.

This adds back a check that got lost in the translation from
modifier_inc to ArithmeticNode.
Branch:master
https://github.com/mongodb/mongo/commit/30d4f31fee2754a7c39be1c3653956e8953ee21e

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

On FCV 3.4, we check whether the resulting SafeNum is valid before setting the new value. So we get the error message:

"Failed to apply $inc operations to current value ((NumberLong)-9223372036854775808) for document {_id: ObjectId('599edc41b5f538e7eed2b55a')}"

We should probably do the same on FCV 3.6.

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

This ends up being type missing, since that's what SafeNum produces on overflow. I don't think there's a serious problem, and I agree that we should just swallow the error message and output a more friendly one.

Comment by Charlie Swanson [ 23/Aug/17 ]

cc tess.avitabile justin.seyster, it looks like we're hitting this case in setValueSafeNum(), my guess is we're seeing this error from this uassert in ArithmeticNode::apply(), but I haven't confirmed. If so, that would be suspicious, since 'b' started as a NumberLong, and shouldn't have changed to a non-numeric type?

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