During the discussion on the PR for SERVER-134439 (PR #62218), gil.alon@mongodb.com, finley.lau@mongodb.com, and I discussed a risk that a shard could re-resolve a view mid-distributed-operation instead of using the view definition resolved by the router.

The approach taken in SERVER-134439 (and already used by $lookup and $unionWith) is to resolve the view in one place in the distributed operation and then "lock it down" by serializing both the resolved (backing) namespace and the resolved pipeline out to all sub-requests. For $graphLookup this is done via $_internalFromPipeline (see document_source_graph_lookup.cpp, serializeFromAndInternalFromPipeline()). The recipient shard then reconstructs the lookup parameters from the serialized form without re-resolving the view.

However, I'm not sure there's any logic to prevent the resolved namespace from being re-resolved if the recipient shard sees that it has become a view in the meantime. There might be a time-of-check / time-of-use window in this scheme.

This ticket is to investigate this race and determine whether it is reachable, and if so, what the right fix is (e.g. holding a stronger lock or otherwise pinning the namespace identity/definition across the lifetime of the distributed operation). This is not a regression introduced by SERVER-134439; SERVER-134439 simply makes the serialization-based "lock down" pattern more explicit and consistent across $graphLookup, $lookup, and $unionWith, which surfaced the question.