-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Query Execution
-
None
-
Fully Compatible
-
ALL
-
Query Execution 2021-04-19, Query Execution 2021-05-03
Demonstration of the problem against a mongod with SBE enabled:
MongoDB Enterprise > db.c.drop() true MongoDB Enterprise > db.c.insert({a: NumberDecimal("-380.85092727960944")}) WriteResult({ "nInserted" : 1 }) MongoDB Enterprise > db.c.aggregate([{$project: {out: {$add: "$a"}}}]) { "_id" : ObjectId("60789c93529583162225a821"), "out" : NumberDecimal("0") }
Here, the $add expression ends up evaluating to 0. This does not seem like the correct behavior. Indeed, with SBE off an $add with a single argument ends up being a no-op:
MongoDB Enterprise > db.c.aggregate([{$project: {out: {$add: "$a"}}}])
{ "_id" : ObjectId("60789c93529583162225a821"), "out" : NumberDecimal("-380.85092727960944") }
This problem was detected by the aggregation_expression_multiversion_fuzzer. See this example failing task.
Here is the SBE plan, with same additional whitespace added for legibility:
[2] traverse s8 s7 s2 {} {}
from
[1] scan s2 s3 [] @\"d0d922c5-fea8-408a-8c53-32726c6995a9\" true
in
[2] mkbson s7 s2 [] keep [a = s6] true false
[2] project [s6 = let [l1.0 = s5]
if (! exists (l1.0) || typeMatch (l1.0, 0x00000440),
null,
if (! isNumber (l1.0) && ! isDate (l1.0),
fail ( 4974203 ,only numbers and dates are allowed in an $add expression),
doubleDoubleSum (l1.0)))]
[2] traverse s5 s5 s4 {} {}
from
[2] project [s4 = getField (s2, \"num\")]
[2] limit 1
[2] coscan
in
[2] project [s5 = s4]
[2] limit 1
[2] coscan
At a glance, it appears that perhaps the "doubleDoubleSum" builtin function is doing the wrong thing?
- is depended on by
-
SERVER-56119 Enable generational agg and query fuzzer suites for "Classic Execution Engine" build variant
-
- Closed
-