[SERVER-56504] [sbe][query_fuzzer_sharded] SBE query results do not match classic engine Created: 29/Apr/21  Updated: 03/May/21  Resolved: 30/Apr/21

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

Type: Bug Priority: Major - P3
Reporter: Kyle Suarez Assignee: Eric Cox (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-52799 Make sbe the default execution engine... Closed
Duplicate
duplicates SERVER-56503 [sbe][query_fuzzer_standalone] SBE re... Closed
Related
related to SERVER-56152 SBE doesn't handle ExprMatchExpressio... Closed
Operating System: ALL
Sprint: Query Execution 2021-05-03, Query Execution 2021-05-17
Participants:

 Description   

In this task:

[js_test:query_fuzzer-2eaf33-1619674683229-3] Unexpected failure for command: {
[js_test:query_fuzzer-2eaf33-1619674683229-3] 	"find" : "fuzzer_coll",
[js_test:query_fuzzer-2eaf33-1619674683229-3] 	"filter" : {
[js_test:query_fuzzer-2eaf33-1619674683229-3] 		"$expr" : {
[js_test:query_fuzzer-2eaf33-1619674683229-3] 			"$dateFromParts" : {
[js_test:query_fuzzer-2eaf33-1619674683229-3] 				"year" : NumberLong(19),
[js_test:query_fuzzer-2eaf33-1619674683229-3] 				"hour" : 2,
[js_test:query_fuzzer-2eaf33-1619674683229-3] 				"millisecond" : {
[js_test:query_fuzzer-2eaf33-1619674683229-3] 					"$ln" : "$obj.obj.obj.obj.num"
[js_test:query_fuzzer-2eaf33-1619674683229-3] 				},
[js_test:query_fuzzer-2eaf33-1619674683229-3] 				"timezone" : "-8949"
[js_test:query_fuzzer-2eaf33-1619674683229-3] 			}
[js_test:query_fuzzer-2eaf33-1619674683229-3] 		}
[js_test:query_fuzzer-2eaf33-1619674683229-3] 	},
[js_test:query_fuzzer-2eaf33-1619674683229-3] 	"projection" : {
[js_test:query_fuzzer-2eaf33-1619674683229-3] 		"obj.obj.obj.obj.obj" : 0,
[js_test:query_fuzzer-2eaf33-1619674683229-3] 		"obj.obj.obj.obj.array" : 0,
[js_test:query_fuzzer-2eaf33-1619674683229-3] 		"num" : 0,
[js_test:query_fuzzer-2eaf33-1619674683229-3] 		"sortKey" : {
[js_test:query_fuzzer-2eaf33-1619674683229-3] 			"$meta" : "sortKey"
[js_test:query_fuzzer-2eaf33-1619674683229-3] 		}
[js_test:query_fuzzer-2eaf33-1619674683229-3] 	},
[js_test:query_fuzzer-2eaf33-1619674683229-3] 	"sort" : {
[js_test:query_fuzzer-2eaf33-1619674683229-3] 		"obj.obj" : 1,
[js_test:query_fuzzer-2eaf33-1619674683229-3] 		"date" : -1,
[js_test:query_fuzzer-2eaf33-1619674683229-3] 		"_id" : 1
[js_test:query_fuzzer-2eaf33-1619674683229-3] 	},
[js_test:query_fuzzer-2eaf33-1619674683229-3] 	"limit" : 12
[js_test:query_fuzzer-2eaf33-1619674683229-3] }
[js_test:query_fuzzer-2eaf33-1619674683229-3] Error: Find and aggregate commands failed with different errors: [null] != [Error: error: {
[js_test:query_fuzzer-2eaf33-1619674683229-3] 	"ok" : 0,
[js_test:query_fuzzer-2eaf33-1619674683229-3] 	"errmsg" : "PlanExecutor error during aggregation :: caused by :: 'millisecond' must evaluate to an integer",
[js_test:query_fuzzer-2eaf33-1619674683229-3] 	"code" : 4848979,
[js_test:query_fuzzer-2eaf33-1619674683229-3] 	"codeName" : "Location4848979",
[js_test:query_fuzzer-2eaf33-1619674683229-3] 	"$clusterTime" : {
[js_test:query_fuzzer-2eaf33-1619674683229-3] 		"clusterTime" : Timestamp(1619674791, 38),
[js_test:query_fuzzer-2eaf33-1619674683229-3] 		"signature" : {
[js_test:query_fuzzer-2eaf33-1619674683229-3] 			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
[js_test:query_fuzzer-2eaf33-1619674683229-3] 			"keyId" : NumberLong(0)
[js_test:query_fuzzer-2eaf33-1619674683229-3] 		}
[js_test:query_fuzzer-2eaf33-1619674683229-3] 	},
[js_test:query_fuzzer-2eaf33-1619674683229-3] 	"operationTime" : Timestamp(1619674791, 38)
[js_test:query_fuzzer-2eaf33-1619674683229-3] }] :



 Comments   
Comment by Kyle Suarez [ 30/Apr/21 ]

eric.cox, I filed TIG-3001; I'm going to resolve this ticket as a duplicate of that one.

Comment by Eric Cox (Inactive) [ 30/Apr/21 ]

anton.korshunov, martin.neupauer, kyle.suarez I can apply the same fix to the query fuzzer too. Send me a ticket.

Comment by Anton Korshunov [ 30/Apr/21 ]

martin.neupauer Oh, it must be related to this.

eric.cox fixed it in the agg fuzzer, but it does seem to exist in the query fuzzer as well.

Comment by Kyle Suarez [ 30/Apr/21 ]

martin.neupauer is right:

@xerograph:~ ♥ server --dbpath ~/dbpath --logpath ~/dbpath/mongod.log --fork --setParameter="featureFlagSBE=false"
about to fork child process, waiting until server is ready for connections.
forked process: 22693
child process started successfully, parent exiting
 
@xerograph:~ ♥ shell
MongoDB server version: 0.0.0                                                                                                                                                                                                                                                   
> db.coll.insert({x: 5})
WriteResult({ "nInserted" : 1 })
> db.coll.find({$expr: {$dateFromParts: {year: NumberLong(19),hour: 2, millisecond: {$ln: "$x"}, timezone: "-5"}}})
Error: error: {
        "ok" : 0,
        "errmsg" : "Executor error during find command :: caused by :: 'millisecond' must evaluate to an integer, found double with value 1.60944",
        "code" : 40515,
        "codeName" : "Location40515"
}

I've updated the title and description to be more in line with Martin's findings.

Comment by Martin Neupauer [ 30/Apr/21 ]

There is nothing wrong with $ln or $dateFromParts.

 

It just in the classic run we never see the input document that can cause problems but SBE sees the document and correctly report an error.

Why the discrepancy? No idea.

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