[SERVER-57854] Changed behavior in SBE when filter is {"":null} Created: 20/Jun/21  Updated: 29/Oct/23  Resolved: 09/Sep/21

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

Type: Question Priority: Major - P3
Reporter: Tomer Yakir Assignee: Andrii Dobroshynski (Inactive)
Resolution: Fixed Votes: 0
Labels: sbe-diff, sbe-post-v1, sbe-rollout
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Related
related to SERVER-64123 $elemMatch value predicate causes que... Closed
related to SERVER-57758 Turn SBE off by default and invert th... Closed
is related to SERVER-59757 Evaluate supporting queries with matc... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v5.0
Sprint: Query Execution 2021-07-26, QE 2021-08-09, QE 2021-08-23, QE 2021-09-06, QE 2021-09-20
Participants:

 Description   

On the legacy query engine (4.4, 5.0 with internalQueryForceClassicEngine), passing on a filter object with the form

{"": null}

evaluates as true and returns all docs.
However on the new query engine it evaluates as false.

This was observed by a test case with the Go Driver passing bson.D{{}} as the filter.
Changing to bson.D{} (which translates to filter: {}) works around the issue.



 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 David Storch [ 21/Sep/21 ]

kyle.suarezjennifer.peshansky, nice! Can we make this an explicit goal of SERVER-59178? We're going to run into more annoyances like this if we keep accidentally enabling SBE for 5.0 nodes in our multiversion test suites.

Comment by Kyle Suarez [ 21/Sep/21 ]

david.storch, this might actually get fixed by jennifer.peshansky as part of SERVER-59178. As part of that ticket, I was thinking we (once again) flip the query knob and rename it to "internalQueryForceClassicEngine". That parameter would not exist in 5.0, and so the multiversion suite should not then attempt to enable SBE. (Right now it's setting internalQueryForceSBEEngine on both, as far as we can tell.)

Comment by Githook User [ 07/Sep/21 ]

Author:

{'name': 'Andrii Dobroshynski', 'email': 'andrii.dobroshynski@mongodb.com', 'username': 'dobroshynski'}

Message: SERVER-57854 Fallback to classic engine for queries with match expressions on empty field names
Branch: master
https://github.com/mongodb/mongo/commit/0e0dd582fa89e28c18af5f33d7383ad30b3a374d

Comment by Ethan Zhang (Inactive) [ 22/Jun/21 ]

We will put this in the future sprint and investigate what is the right behavior.

Comment by Ethan Zhang (Inactive) [ 22/Jun/21 ]

I actually found any non-existent fields with null value will be true, so I am not 100% convinced that this is just incidental behavior, it makes a bit of sense semantically, although still very strange.

> db.test.find()
{ "_id" : ObjectId("60d1797899f4777b8ec65c41"), "a" : 10 }
> db.test.find({"": null})
{ "_id" : ObjectId("60d1797899f4777b8ec65c41"), "a" : 10 }
> db.test.find({"": 1})
> db.test.find({"non-existent": null})
{ "_id" : ObjectId("60d1797899f4777b8ec65c41"), "a" : 10 }
> db.test.find({"non-existent": 1})
> 

Comment by David Storch [ 21/Jun/21 ]

The server currently doesn't fully support queries over data with empty key names. You can't create an index over a path with an empty key name:

MongoDB Enterprise > db.c.createIndex({"": 1})
{
	"ok" : 0,
	"errmsg" : "Error in specification { key: { : 1.0 }, name: \"_1\" } :: caused by :: Index keys cannot be an empty field.",
	"code" : 67,
	"codeName" : "CannotCreateIndex"
}
MongoDB Enterprise > db.c.createIndex({"a.": 1})
{
	"ok" : 0,
	"errmsg" : "Error in specification { key: { a.: 1.0 }, name: \"a._1\" } :: caused by :: Index keys cannot contain an empty field.",
	"code" : 67,
	"codeName" : "CannotCreateIndex"
}

And you can't specify an empty key name in a field path expression in aggregation:

MongoDB Enterprise > db.c.aggregate([{$project: {out: "$"}}])
uncaught exception: Error: command failed: {
	"ok" : 0,
	"errmsg" : "Invalid $project :: caused by :: '$' by itself is not a valid FieldPath",
	"code" : 16872,
	"codeName" : "Location16872"
} with original command request: {
	"aggregate" : "c",
	"pipeline" : [
		{
			"$project" : {
				"out" : "$"
			}
		}
	],
	"cursor" : {
 
	},
	"lsid" : {
		"id" : UUID("a216c39f-d935-47da-841f-adf9a79d2045")
	}
} on connection: connection to 127.0.0.1:27017 : aggregate failed :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
doassert@src/mongo/shell/assert.js:18:14
_assertCommandWorked@src/mongo/shell/assert.js:731:17
assert.commandWorked@src/mongo/shell/assert.js:823:16
DB.prototype._runAggregate@src/mongo/shell/db.js:276:5
DBCollection.prototype.aggregate@src/mongo/shell/collection.js:1058:12
@(shell):1:1
MongoDB Enterprise > db.c.aggregate([{$project: {out: "$a."}}])
uncaught exception: Error: command failed: {
	"ok" : 0,
	"errmsg" : "Invalid $project :: caused by :: FieldPath must not end with a '.'.",
	"code" : 40353,
	"codeName" : "Location40353"
} with original command request: {
	"aggregate" : "c",
	"pipeline" : [
		{
			"$project" : {
				"out" : "$a."
			}
		}
	],
	"cursor" : {
 
	},
	"lsid" : {
		"id" : UUID("a216c39f-d935-47da-841f-adf9a79d2045")
	}
} on connection: connection to 127.0.0.1:27017 : aggregate failed :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
doassert@src/mongo/shell/assert.js:18:14
_assertCommandWorked@src/mongo/shell/assert.js:731:17
assert.commandWorked@src/mongo/shell/assert.js:823:16
DB.prototype._runAggregate@src/mongo/shell/db.js:276:5
DBCollection.prototype.aggregate@src/mongo/shell/collection.js:1058:12
@(shell):1:1

Interestingly, we do seem to support empty key names in the match expression language. I would guess that this behavior is incidental as opposed to being explicitly designed and implemented this way. Examples:

MongoDB Enterprise > db.c.find({"": 1})
{ "_id" : ObjectId("60d100af23e917f20fa01a95"), "" : 1 }
MongoDB Enterprise > db.c.find({"a.": 1})
{ "_id" : ObjectId("60d100a023e917f20fa01a94"), "a" : { "" : 1 } }
MongoDB Enterprise > db.c.find({"a..": 1})
{ "_id" : ObjectId("60d100b923e917f20fa01a96"), "a" : { "" : { "" : 1 } } }

Whether or not a predicate such as {"": 1} is even supposed to be meaningful is an open question. But it does seem to be broken when SBE is enabled, for a reason that has not yet been investigated.

Comment by Kyle Suarez [ 21/Jun/21 ]

Note that we are disabling SBE by default for v5.0 in SERVER-57758, so this issue will be resolved in the short term by that change by reverting to the classic engine's behavior. I am sending this ticket to the triage queue for QE to discuss future behavior in SBE.

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