Background

When a sharded $search query requires $$SEARCH_META, the router splits the pipeline and injects the shards' metadata cursors into the merge half's $setVariableFromSubPipeline sub-pipeline (injectMetaCursor). The design assumes that a merge pipeline containing this stage always executes on the router; the injected metadata DocumentSourceMergeCursors has no serialization path, so if the merge half is ever dispatched to a shard, the sub-pipeline arrives as the bare metaPipeline with no cursor source and the shard trips tassert 6448002.

AF-18751 saw one production occurrence of a router delegating such a merge to a shard (8.0.x), and SERVER-131820 aims to add a defensive layer by failing the operation cleanly with actionable errors at the router boundary and at the shard/mongot contract boundary, with the executor tassert retained as a backstop. Extensive repro attempts (real-mongot e2e, mongotmock replays of the production cluster's query shapes, both read preferences, single-shard chunk placement, cursor under-return) could not trigger the delegation path on master or 8.0, so the root of why the router delegated remains unidentified.

Proposed work

The structural fix is serialization parity between the data and metadata cursors: the data-half $mergeCursors already serializes its remotes (shard ids, hosts, live cursor ids) and hands cursor ownership to a merging shard — that mechanism works today. If the metadata $mergeCursors injected into the $setVariableFromSubPipeline sub-pipeline serialized the same way, a shard-delegated merge would simply work, and the invariant "setVariable merges never leave the router" would no longer be load-bearing.

Scope to investigate:

• Serialization/reparse of the injected sub-pipeline source in createCommandForMergingShard and the shard-side reparse path.
• Cursor ownership/session semantics when the metadata cursors transfer to the merging shard (mirror what the data half does).
• Whether $setVariableFromSubPipeline's host-type constraint can then be relaxed, or whether router-merge should remain preferred with delegation merely tolerated.
• Alternatively/additionally: identify the router code path that chose shard-merge in the original occurrence, and decide whether to fix the decision instead of legitimizing it.

Why this was deferred from SERVER-131820

• The delegation path could not be reproduced, so the fix would ship without a test that proves it addresses the original failure; the shipped uasserts give clean, diagnosable failures in the meantime and will pinpoint the path if it recurs.
• The change touches cursor-ownership machinery on the $search merge path and would need backports to 8.0/9.0; doing this around the 9.0 release adds unnecessary upgrade risk.

Acceptance

Either (a) metadata cursors survive merge delegation end-to-end with a regression test exercising a shard-delegated merge, or (b) a documented decision that router-only is the contract, with the delegation decision path fixed/asserted at its source.