[SERVER-53900] Ensure expression arguments checks semantics are the same between classic and SBE engines Created: 20/Jan/21  Updated: 25/Jun/21  Resolved: 22/Apr/21

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

Type: Task Priority: Major - P3
Reporter: Anton Korshunov Assignee: Andrii Dobroshynski (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-56119 Enable generational agg and query fuz... Closed
Duplicate
is duplicated by SERVER-56084 [SBE] aggregation_multiversion_fuzzer... Closed
Related
related to SERVER-58095 Implement a workaround for cases wher... Closed
related to SERVER-56278 Make $replaceOne check for any null a... Backlog
Sprint: Query Execution 2021-02-22, Query Execution 2021-03-08, Query Execution 2021-03-22, Query Execution 2021-04-05, Query Execution 2021-04-19, Query Execution 2021-05-03
Participants:

 Description   

In a CR forĀ SERVER-51666 it was pointed out that there could be some inconsistencies between how expression argument checks are done in the classic in SBE engines. For example, in the classic engine some expressions may follow all-checks-per-argument rule (by applying all checks on one arguments before moving to the next one), whilst in SBE the same expression may follow one-check-for-all-arguments rule (when we apply a specific check for all arguments before moving to the next type of check, for example check all arguments for null, and then validate the range). We should keep this behaviour consistent between the two engines and will need to investigate and find all expressions in SBE which check arguments differently than their counterparts in the classic engine and address such inconsistencies.



 Comments   
Comment by David Storch [ 15/Apr/21 ]

I saw the $concat example show up in this aggregation_expression_multiversion_fuzzer task! The fuzzer reports that version 1 returned a result set, but version 2 produced an error:

[js_test:agg_expr_fuzzer-01c5-1618503526152-0] Error: Aggregation failed. Version 1 returned a result set. For example: {  "a" : null }
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] Version 2 returned error: [Error: command failed: {
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 	"ok" : 0,
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 	"errmsg" : "$concat only supports strings, not double",
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 	"code" : 16702,
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 	"codeName" : "Location16702"
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] } with original command request: {
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 	"aggregate" : "fuzzer_coll",
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 	"pipeline" : [
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 		{
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 			"$project" : {
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 				"a" : {
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 					"$concat" : [
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 						"$obj.str",
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 						"$obj.obj.obj.obj.str"
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 					]
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 				},
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 				"_id" : 0
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 			}
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 		}
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 	],
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 	"maxTimeMS" : 30000,
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 	"cursor" : {
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 	},
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 	"lsid" : {
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 		"id" : UUID("c56b28d5-8c18-4844-8391-0136a063c253")
[js_test:agg_expr_fuzzer-01c5-1618503526152-0] 	}

As part of this ticket, we need to turn the aggregation_expression_multiversion_fuzzer green. We need to decide whether to do so by either changing the structure of the plan generated by sbe_stage_builder_expression.cpp to match the semantics of the classic engine, or to relax the fuzzer so that it does not report a test failure in this scenario.

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