[SERVER-54497] [SBE] Error is not returned as expected in jstests/core/ord.js Created: 12/Feb/21  Updated: 23/Feb/21  Resolved: 23/Feb/21

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

Type: Bug Priority: Major - P3
Reporter: Anton Korshunov Assignee: David Storch
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-49385 SBE should fail cleanly if needed ind... Closed
Operating System: ALL
Steps To Reproduce:

resmoke run --suite=core_sbeĀ jstests/core/ord.js

Sprint: Query Execution 2021-03-08
Participants:

 Comments   
Comment by David Storch [ 23/Feb/21 ]

mihai.andrei is correct – this is a duplicate of SERVER-49385. I am closing this ticket as such. I confirmed that my in-progress patch for SERVER-49385 allows the sbe_incompatible tag to be removed from ord.js.

Comment by Mihai Andrei [ 23/Feb/21 ]

jstests/core/ord.js fails on the following line because the index drop should kill all cursors on the indexed namespace. For context the explain plan looks like this:

{
 	"explainVersion" : "2",
 	"queryPlanner" : {
 		"namespace" : "test.jstests_ord",
 		"indexFilterSet" : false,
 		"parsedQuery" : {
 			"$or" : [
 				{
 					"a" : {
 						"$eq" : 1
 					}
 				},
 				{
 					"b" : {
 						"$eq" : 1
 					}
 				}
 			]
 		},
 		"queryHash" : "F4D30AA0",
 		"planCacheKey" : "7BEAA584",
 		"maxIndexedOrSolutionsReached" : false,
 		"maxIndexedAndSolutionsReached" : false,
 		"maxScansToExplodeReached" : false,
 		"winningPlan" : {
 			"queryPlan" : {
 				"stage" : "FETCH",
 				"planNodeId" : 4,
 				"inputStage" : {
 					"stage" : "OR",
 					"planNodeId" : 3,
 					"inputStages" : [
 						{
 							"stage" : "IXSCAN",
 							"planNodeId" : 1,
 							"keyPattern" : {
 								"a" : 1
 							},
 							"indexName" : "a_1",
 							"isMultiKey" : false,
 							"multiKeyPaths" : {
 								"a" : [ ]
 							},
 							"isUnique" : false,
 							"isSparse" : false,
 							"isPartial" : false,
 							"indexVersion" : 2,
 							"direction" : "forward",
 							"indexBounds" : {
 								"a" : [
 									"[1.0, 1.0]"
 								]
 							}
 						},
 						{
 							"stage" : "IXSCAN",
 							"planNodeId" : 2,
 							"keyPattern" : {
 								"b" : 1
 							},
 							"indexName" : "b_1",
 							"isMultiKey" : false,
 							"multiKeyPaths" : {
 								"b" : [ ]
 							},
 							"isUnique" : false,
 							"isSparse" : false,
 							"isPartial" : false,
 							"indexVersion" : 2,
 							"direction" : "forward",
 							"indexBounds" : {
 								"b" : [
 									"[1.0, 1.0]"
 								]
 							}
 						}

Indeed, the query fails with the following uassert because each IXSCAN calls 'RequiresIndexStage::doRestoreStateRequiresCollection()' after the index drop (the parent OR will unconditionally reopen all of its child stages). As such, I believe this test is related to the work in SERVER-49385, since 'ord.js' appears to be testing this behavior.

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