-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Query Integration
-
Fully Compatible
-
v9.0
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Problem
When featureFlagSearchExtension is enabled, a query that nests $unionWith and $lookup sub-pipelines containing an extension $search against views returns incorrect results on an unsharded (single-node) deployment: deeply-nested sub-pipeline results are dropped. The command succeeds (ok: 1) but the returned document set does not match the expected set.
This is distinct from the sharded failure of the same test, which trips Location12761201 ("internalFieldMatchPipelineIdx out of range of resolvedPipeline") and is tracked by SERVER-131212. On a single node there is no tripwire/crash — just a silent result mismatch.
Environment / Repro
- Suite: with_mongot_extension_vectorSearch_disabled_single_node (flags: featureFlagSearchExtension: true, featureFlagVectorSearchExtension: false, featureFlagExtensionsInsideHybridSearch: true).
- Test: {
Unknown macro: {jstests/with_mongot/e2e/views/search/unionWith_lookup_nested_deep.js}
}
- Topology: single node. Reproduced deterministically (not flaky/order-dependent).
The test issues nested $unionWith + $lookup pipelines whose sub-pipelines run $search against views (a view whose foreign namespace is itself another view), then compares the result set with assertArrayEq.
Expected vs Actual
- Expected: full result set, including documents produced by the deeply-nested $unionWith/$lookup-on-view sub-pipelines.
- Actual: assertArrayEq fails — the deeply-nested results are missing from the actual array. Top-level and first-level view transforms are applied, but the innermost $lookup/$unionWith-on-view sub-operations return no rows.
[js_test:unionWith_lookup_nested_deep] assert failed : actual=[ ... ] (missing deeply-nested union/lookup results)
assertArrayEq@jstests/aggregation/extras/utils.js:476
Hypothesis
Under the extension path, the resolved view is not propagated to deeply-nested $unionWith/$lookup sub-pipelines, so those nested stages scan the underlying collection instead of the view and yield no matching rows. View binding appears to work for the top and first level but not for further-nested sub-pipelines.
Impact
- Silent data loss: an accepted query returns an incomplete result set (worse than an outright error).
- Behavioral divergence between the legacy and extension $search paths for nested view sub-pipelines.
Notes
- Currently excluded via buildscripts/resmokeconfig/matrix_suites/overrides/with_mongot_extension.yml (exclude_search_extension_incompatible) with a placeholder TODO pointing at this ticket. Excluded family-wide because the same test also fails on sharded topologies via
SERVER-131212. - Related files: src/mongo/db/pipeline/document_source_lookup.cpp, src/mongo/db/pipeline/document_source_union_with.cpp, src/mongo/db/pipeline/pipeline_factory.cpp (view binding / resolveInvolvedNamespaces for nested sub-pipelines).
- is related to
-
SERVER-131212 $lookup field-match placed incorrectly for extension mongot search subpipelines
-
- Closed
-
- related to
-
SERVER-131738 Complete TODO listed in SERVER-131409
-
- Closed
-
-
SERVER-131677 Unify the desugar + resolve namespaces API
-
- Needs Scheduling
-