[SERVER-63017] Fix SBE translation of variadic expressions for zero argument case Created: 26/Jan/22  Updated: 29/Oct/23  Resolved: 28/Jan/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: Backlog
Fix Version/s: 5.3.0

Type: Task Priority: Major - P3
Reporter: Mihai Andrei Assignee: Irina Yatsenko (Inactive)
Resolution: Fixed Votes: 0
Labels: greenerbuild
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Related
related to SERVER-63008 [SBE] $concatArrays implementation sh... Closed
related to SERVER-63012 Initialize $add with no operands to z... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v5.2
Participants:
Linked BF Score: 185

 Description   

Recently, two bugs were found by the fuzzer (SERVER-63008 and SERVER-63012) where SBE translation of certain variadic expressions did not account for the 0 child case. (presumably, because when optimization is enabled, the expression gets optimized away and never gets pushed down to SBE). This ticket fixes the remaining variadic expression SBE translations that suffer from this same bug.



 Comments   
Comment by Githook User [ 02/Feb/22 ]

Author:

{'name': 'Irina Yatsenko', 'email': 'irina.yatsenko@mongodb.com', 'username': 'IrinaYatsenko'}

Message: SERVER-63017 Handle no arguments case in un-optimized agg operators

(cherry picked from commit 59e5b09e6840c5d00fbc961f812d66a00f823938)
Branch: v5.2
https://github.com/mongodb/mongo/commit/207b1091cf43c3abcc30267cde3905b4fd63fca2

Comment by Mihai Andrei [ 28/Jan/22 ]

Sure; I'll close this one and file a follow up.

Filed https://jira.mongodb.org/browse/SERVER-63080

Comment by Kyle Suarez [ 27/Jan/22 ]

irina.yatsenko and mihai.andrei, from a ticket maintenance standpoint – I would like to close this ticket and give it an appropriate fix version, given that Irina has committed something to master. If there is follow-on work, we can track it separately by filing a follow-up ticket. Does that sound acceptable?

Comment by Irina Yatsenko (Inactive) [ 27/Jan/22 ]

Per discussion with mihai.andrei keeping the ticket open to investigate if any more hardening is needed in the SBE expression translators (and/or more test coverage).

Comment by Githook User [ 27/Jan/22 ]

Author:

{'name': 'Irina Yatsenko', 'email': 'irina.yatsenko@mongodb.com', 'username': 'IrinaYatsenko'}

Message: SERVER-63017 Handle no arguments case in un-optimized agg operators
Branch: master
https://github.com/mongodb/mongo/commit/59e5b09e6840c5d00fbc961f812d66a00f823938

Comment by Irina Yatsenko (Inactive) [ 26/Jan/22 ]

I've looked through publicly documented Aggregation Pipeline Operators (https://docs.mongodb.com/manual/reference/operator/aggregation) for those that have signature of {$op:{ $setEquals: [ <expression1>, <expression2>, ... ] }} and found the following:

$and, $or handle no args with default values of true/false respectively.
$setEquals fails the query with "$setEquals needs at least two arguments had: 0"

$add, $concat, $concatArrays, $multiply, $setIntersection, $setUnion – fail with the server invariant

SERVER-63012 addresses $add
SERVER-63008 addresses $concatArrays

Note: the public documentation for $setUnion and $setIntersection says "Takes two or more arrays and returns an array that contains the elements that appear in every input array." but both return an empty set when optimizations are enabled. Similarly, the public documentation for $and/$or requires at least one argument but we actually handle zero. Should the docs be updated?

Generated at Thu Feb 08 05:56:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.