-
Type: Bug
-
Resolution: Works as Designed
-
Priority: Major - P3
-
None
-
Affects Version/s: 5.0.0
-
Component/s: None
-
None
-
ALL
-
Query Optimization 2021-05-31, Query Optimization 2021-06-14
A user in mongodb/mongo-php-library#536 shared an aggregation pipeline with a $match stage and what appeared to be an invalid value for $expr. Quoting the aggregation expression docs:
Expressions can include field paths, literals, system variables, expression objects, and expression operators. Expressions can be nested.
I assume value expressions are strings and BSON documents. In the issue, the user was providing a BSON array.
I attempted to reproduce this locally with version 5.0.0-alpha0-282-g7b9eb05 (gitVersion: 7b9eb05ea26dd0adba9c097ba1fe68dc3c2e1ba1) and observed the following:
rs0:PRIMARY> db.foo.find() { "_id" : ObjectId("609eb06d9c3fd06ec84b2ead"), "x" : 1 } rs0:PRIMARY> db.foo.aggregate([{$match:{$expr:[]}}]) { "_id" : ObjectId("609eb06d9c3fd06ec84b2ead"), "x" : 1 }
I also tried some other values that I expected would be invalid:
rs0:PRIMARY> db.foo.aggregate([{$match:{$expr:{0:1}}}]) { "_id" : ObjectId("609eb06d9c3fd06ec84b2ead"), "x" : 1 } rs0:PRIMARY> db.foo.aggregate([{$match:{$expr:{foo:1}}}]) { "_id" : ObjectId("609eb06d9c3fd06ec84b2ead"), "x" : 1 }
Using an unsupported operator (e.g. $foo) does result in an error. But in the examples above it looks like the expression was simply ignored. Is this expected behavior, or should the server be more strict about validating the expression value?