[SERVER-57077] Tests are seeing an unexpected plan object shape when SBE is allegedly enabled in sharding_jscore_multiversion_passthrough Created: 19/May/21  Updated: 29/Oct/23  Resolved: 20/May/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 5.0.0-rc0
Fix Version/s: 5.0.0-rc0, 5.1.0-rc0

Type: Bug Priority: Major - P3
Reporter: Kyle Suarez Assignee: Kyle Suarez
Resolution: Fixed Votes: 0
Labels: post-rc0, sbe-post-rc0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v5.0
Steps To Reproduce:

link title

Sprint: Query Execution 2021-05-31
Participants:
Linked BF Score: 84

 Description   

It appears like the classic execution engine is being used even though we expect SBE to be enabled. See this Evergreen build. The problem manifests in different ways.

For example, plan_cache_sbe.js expects that a cached plan has cachedPlan.queryPlan.slotBasedPlan, but cachedPlan.queryPlan does not exist.

[js_test:plan_cache_sbe] assert: [false] != [true] are not equal : {
[js_test:plan_cache_sbe] 	"queryHash" : "4B53BE76",
[js_test:plan_cache_sbe] 	"planCacheKey" : "4281AFAD",
[js_test:plan_cache_sbe] 	"isActive" : false,
[js_test:plan_cache_sbe] 	"works" : NumberLong(2),
[js_test:plan_cache_sbe] 	"timeOfCreation" : ISODate("2021-05-18T05:07:37.881Z"),
[js_test:plan_cache_sbe] 	"createdFromQuery" : {
[js_test:plan_cache_sbe] 		"query" : {
[js_test:plan_cache_sbe] 			"a" : 1
[js_test:plan_cache_sbe] 		},
[js_test:plan_cache_sbe] 		"sort" : {
[js_test:plan_cache_sbe] 
[js_test:plan_cache_sbe] 		},
[js_test:plan_cache_sbe] 		"projection" : {
[js_test:plan_cache_sbe] 
[js_test:plan_cache_sbe] 		}
[js_test:plan_cache_sbe] 	},
[js_test:plan_cache_sbe] 	"cachedPlan" : {
[js_test:plan_cache_sbe] 		"stage" : "FETCH",
[js_test:plan_cache_sbe] 		"inputStage" : {
[js_test:plan_cache_sbe] 			"stage" : "IXSCAN",
[js_test:plan_cache_sbe] 			"keyPattern" : {
[js_test:plan_cache_sbe] 				"a" : 1
[js_test:plan_cache_sbe] 			},
[js_test:plan_cache_sbe] 			"indexName" : "a_1",
[js_test:plan_cache_sbe] 			"isMultiKey" : false,
[js_test:plan_cache_sbe] 			"multiKeyPaths" : {
[js_test:plan_cache_sbe] 				"a" : [ ]
[js_test:plan_cache_sbe] 			},
[js_test:plan_cache_sbe] 			"isUnique" : false,
[js_test:plan_cache_sbe] 			"isSparse" : false,
[js_test:plan_cache_sbe] 			"isPartial" : false,
[js_test:plan_cache_sbe] 			"indexVersion" : 2,
[js_test:plan_cache_sbe] 			"direction" : "forward",
[js_test:plan_cache_sbe] 			"indexBounds" : {
[js_test:plan_cache_sbe] 				"a" : [
[js_test:plan_cache_sbe] 					"[1.0, 1.0]"
[js_test:plan_cache_sbe] 				]
[js_test:plan_cache_sbe] 			}
[js_test:plan_cache_sbe] 		}
[js_test:plan_cache_sbe] 	},

In idhack.js, we are expecting an IXSCAN because SBE is enabled but instead see the classic engine's IDHACK:

[js_test:idhack] assert: [null] != [null] are equal : {
[js_test:idhack] 	"stage" : "SINGLE_SHARD",
[js_test:idhack] 	"shards" : [
[js_test:idhack] 		{
[js_test:idhack] 			"shardName" : "shard-rs1",
[js_test:idhack] 			"connectionString" : "shard-rs1/localhost:20504,localhost:20505",
[js_test:idhack] 			"serverInfo" : {
[js_test:idhack] 				"host" : "ip-10-122-51-138",
[js_test:idhack] 				"port" : 20504,
[js_test:idhack] 				"version" : "4.4.6-36-g1ed404e",
[js_test:idhack] 				"gitVersion" : "1ed404ec8f163dab3ef598cb159e0524939f0066"
[js_test:idhack] 			},
[js_test:idhack] 			"plannerVersion" : 1,
[js_test:idhack] 			"namespace" : "test.idhack",
[js_test:idhack] 			"indexFilterSet" : false,
[js_test:idhack] 			"parsedQuery" : {
[js_test:idhack] 				"_id" : {
[js_test:idhack] 					"$eq" : {
[js_test:idhack] 						"x" : 2
[js_test:idhack] 					}
[js_test:idhack] 				}
[js_test:idhack] 			},
[js_test:idhack] 			"winningPlan" : {
[js_test:idhack] 				"stage" : "IDHACK"
[js_test:idhack] 			},
[js_test:idhack] 			"rejectedPlans" : [ ]
[js_test:idhack] 		}
[js_test:idhack] 	]
[js_test:idhack] }



 Comments   
Comment by Vivian Ge (Inactive) [ 06/Oct/21 ]

Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you!

Comment by Githook User [ 20/May/21 ]

Author:

{'name': 'Kyle Suarez', 'email': 'kyle.suarez@mongodb.com', 'username': 'ksuarz'}

Message: SERVER-57077 require FCV 5.0 for tests asserting on query plan shape

(cherry picked from commit b9d0f29acb548cf05cf194a78d5d0516b5ae34fc)
Branch: v5.0
https://github.com/mongodb/mongo/commit/e24b256e97eb739ecfb763d9e6cba7777a32523f

Comment by Githook User [ 20/May/21 ]

Author:

{'name': 'Kyle Suarez', 'email': 'kyle.suarez@mongodb.com', 'username': 'ksuarz'}

Message: SERVER-57077 require FCV 5.0 for tests asserting on query plan shape
Branch: master
https://github.com/mongodb/mongo/commit/b9d0f29acb548cf05cf194a78d5d0516b5ae34fc

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