Background

In SERVER-131409 we discovered that resolveInvolvedNamespacesOnLiteParsedPipeline() must be called on a desugared lite-parsed pipeline. If the view pipeline is not desugared first, nested views inside the subpipelines are not expanded and view resolution silently produces incorrect results.

The fix in aggregation_execution_state.cpp added an explicit desugar step before the resolve call:

if (!entry.getLiteParserOptions()) {
entry.setLiteParserOptions(std::make_shared<LiteParserOptions>(
LiteParserOptions\{.ifrContext = getIfrContext()}));
}
entry.desugarViewPipeline();
PipelineResolver::resolveInvolvedNamespacesOnLiteParsedPipeline(
&entry.getMutableParsedPipeline()->pipeline(),
entry.getResolvedNamespace(),
resolvedNamespaces);

This "desugar first, then resolve" ordering is an implicit contract that the type system does not currently enforce. During review (cswanson310 on PR #58739) it was noted that this class of bug – forgetting to desugar before resolving – could be made impossible with a combined API.

Proposed work

• Investigate combining the desugar step (including LiteParserOptions / ifrContext initialization) and the involved-namespace resolution into a single entry point, so callers get a correctly-desugared pipeline as a precondition of resolution.
• Consider whether the type system can encode "this pipeline has been desugared" (e.g. a distinct type or a wrapper) so that resolveInvolvedNamespacesOnLiteParsedPipeline can only be handed a desugared pipeline.
• Audit the (small number of) existing callers and migrate them to the combined API.

Notes

Investigation during SERVER-131409 found there are only a few callers of resolveInvolvedNamespacesOnLiteParsedPipeline, so consolidating the API is expected to be low-risk. This is explicitly not required for SERVER-131409 – it is a hardening/ergonomics follow-up to prevent future regressions.