[SERVER-54314] Relax field order assertions in jstests/aggregation/sources/project/project_with_expressions.js Created: 04/Feb/21  Updated: 29/Oct/23  Resolved: 18/Feb/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.9.0

Type: Bug Priority: Major - P3
Reporter: Anton Korshunov Assignee: Mihai Andrei
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

resmoke run --suite=aggregation_sbe jstests/aggregation/sources/project/project_with_expressions.js

Sprint: Query Execution 2021-02-22
Participants:

 Comments   
Comment by Githook User [ 18/Feb/21 ]

Author:

{'name': 'Mihai Andrei', 'email': 'mihai.andrei@10gen.com', 'username': 'mtandrei'}

Message: SERVER-54314 Relax field order assertions in jstests/aggregation/sources/project/project_with_expressions.js
Branch: master
https://github.com/mongodb/mongo/commit/1347d04e7d2e9e7940fc5df0e8a32eed9d4a2e07

Comment by Mihai Andrei [ 16/Feb/21 ]

To clarify, the issue appears to reproduce when we have a projection with a mix of inclusion and computed projections. Suppose we have the document {a: 1, b: 2} in a collection 'c' and we run the query db.c.find({}, {_id: 0, a: {$literal: 3}, b: 1})

With the classic engine enabled, we will get { b : 2, a : 3 } (the inclusion projection comes before the computed projection) and with SBE enabled, we get { a : 3, b : 2 } (the fields appear in their original order).

Note that the SBE plan for the above query is as follows:

[2] traverse s6 s5 s2
from
    [1] scan s2 s3 [] @"1b12084b-0f04-4c88-8f80-9b80576bec3a"
in
    [2] cfilter {isObject (s2)}
    [2] mkbson s5 s2 [b, _id] keep [a = s4] true false
    [2] project [s4 = 3]
    [2] limit 1
    [2] coscan

Comment by Mihai Andrei [ 11/Feb/21 ]

This test failure is the result of a divergence between the classic executor and SBE. Whereas the classic engine will apply inclusion projections before applying computed expressions (see also ProjectionNode::applyProjection), SBE will apply projections in the order that fields appear in the original document.

How we decide to fix this test failure depends on how we interpret the above. If we don’t have any strong guarantees about field ordering in projection, then this isn’t a bug in SBE and the above test should be fixed using an unordered field comparator (something like assert.docEq(). If, on the other hand we want the order of fields produced by SBE to match that of the classic engine, then some more thought needs to given about how to accomplish this (I don't think it's as simple as modifying the implementation of the MakeObj stage).

cc ian.boros

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