-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Integration
-
Fully Compatible
-
ALL
-
None
-
None
-
None
-
None
-
None
-
None
-
None
SERVER-130603 fixed a deadlock in the extension $search/$vectorSearch (DRM) path when binding $$SEARCH_META. $_internalDocumentResultsAndMetadata lowers to a single Exchange keyed on _streamType with two consumers over one shared source: consumer 0 = documents, consumer 1 = metadata. The metadata consumer is drained first (standalone: by $setVariableFromSubPipeline; sharded: by the router pulling one $mergeCursors before the other). Because the Exchange only emits EOS at shared-source EOF, draining the metadata consumer forces the entire document stream into consumer 0's 16 MB buffer, which nobody is draining yet — the buffer fills, the loader parks, and the metadata consumer waits forever. Any result set larger than the buffer deadlocks mongod.
SERVER-130603 worked around this by appending $limit:1 to the metadata sub-pipeline, so the metadata binding short-circuits before the document stream is forced through the Exchange. The $limit:1 fix assumes each source emits exactly one metadata document. That holds standalone, but not when sharded: for distributed facets, each shard's mongot returns multiple metadata documents (e.g. facet buckets) that the router merges into one. $limit:1 on the stashed per-shard metadata cursor silently truncates those to a single document, producing incorrect merged $$SEARCH_META. Simply dropping $limit:1 on the sharded branch reintroduces the deadlock, because $setVariableFromSubPipeline polls the metadata and document merge cursors serially even in the sharded case.
- is related to
-
SERVER-130603 $$SEARCH_META deadlocks on standalone when document stream exceeds Exchange buffer
-
- Closed
-