Investigate if fields are propagated correctly from original aggRequest to resolved view aggRequest

    • Type: Task
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Query Optimization
    • None
    • 3
    • TBD
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      While working on SERVER-95749, I discovered that the fromRouter value wasn't being passed from the original aggregate request to the resolved view request, which led to us hitting this uassert in merge_to_referenced_collection.js under the aggregation_unsplittable_collections_on_random_shard_passthrough suite. It looks like ResolvedView::asExpandedViewAggregation() handpicks which fields to pass from the original request to the view request, which strikes me as particularly bug-prone as people add more fields to aggregate_command.idl in the future and may forget to set it here. It's also likely that we are incorrectly failing to pass fields that should remain the same across both requests, but we simply don't have the test coverage to thoroughly explore all code paths.

      This ticket would involve auditing the existing fields that aren't passed, adding those that should be, and potentially restructuring this function to pass all fields by default instead of handpicking fields to pass (similar to SERVER-105351). Another possible approach is to add a linter rule to check whether newly added fields are accounted for in ResolvedView::asExpandedViewAggregation().

            Assignee:
            Unassigned
            Reporter:
            Lynne Wang
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: