Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Fixed
-
None
-
None
-
Fully Compatible
-
ALL
-
v5.0
-
Query Execution 2021-05-31
-
47
Description
The query_fuzzer_sharded picked up on this. I haven't figured out exactly what the problem is yet, but here is a simple repro:
(function() {
|
"use strict";
|
|
const st = new ShardingTest({shards: 1});
|
const db = st.s.getDB("test");
|
|
const shardKey = {
|
num: 1,
|
"obj.str": "hashed"
|
};
|
|
assert.commandWorked(db.createCollection("c"));
|
const coll = db.c;
|
assert.commandWorked(coll.createIndex(shardKey));
|
|
assert.commandWorked(db.adminCommand({enableSharding: "test"}));
|
assert.commandWorked(db.adminCommand({
|
shardCollection: coll.getFullName(),
|
key: shardKey,
|
}));
|
|
assert.eq([], coll.find({num: {$in: [/myRegex/, 1]}}).sort({"obj.obj.obj": 1}).toArray());
|
|
st.stop();
|
}());
|
Note that although this is an "undefined slot accessor" error which can happen in the query fuzzer, it looks like a separate issue from SERVER-56506.
One thing I noticed is that this does not repro unless the $in match expression has a regular expression as one of its arguments. Perhaps some special code in the SBE stage builders for $in with a regex plays badly with how we construct the plan for shard filtering? Just guessing based on the nature of the repro.