jstests/aggregation/illegal_reference_in_match.js


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

// This is intended to reproduce SERVER-39109. The test ensures that when a field path which is
// illegal inside the aggregation system is used in a $match that is not pushed down to the query
// system, the correct error is raised.
(function() {
"use strict";

const coll = db.illegal_reference_in_match;
assert.commandWorked(coll.insert({a: 1}));

const pipeline = [
    // The limit stage prevents the planner from pushing the match into the query layer.
    {$limit: 10},

    // 'a.$c' is an illegal path in the aggregation system (though it is legal in the query
    // system). The $limit above forces this $match to run as an aggregation stage, so the path
    // will be interpreted as illegal.
    {$match: {"a.$c": 4}},

    // This inclusion-projection allows the planner to determine that the only necessary fields
    // we need to fetch from the document are "_id" (by default), "a.$c" (since we do a match
    // on it) and "dummy" since we include/rename it as part of this $project.

    // The reason we need to explicitly include a "dummy" field, rather than just including
    // "a.$c" is that, as mentioned before, a.$c is an illegal path in the aggregation system,
    // so if we use it as part of the project, the $project will fail to parse (and the
    // relevant code will not be exercised).
    {
        $project: {
            "newAndUnrelatedField": "$dummy",
        }
    }
];

const err = assert.throws(() => coll.aggregate(pipeline));
assert.eq(err.code, 16410);
})();