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);
})();