When a $lookup is reading from a sharded collection it will go through the normal shard versioning procedure to establish cursors on all the shards so that everyone agrees on a point-in-time of ownership across the cluster. During this establishment one of the shards may return a stale version error to the $lookup stage. The $lookup stage does not have any logic to handle that error, refresh the sharding catalog cache used for targeting, and retry the cursor establishment. This logic does exist, but the error is retried all the way at the top of the aggregate command, not the $lookup itself. This ticket tracks the work to handle this error and retry within the $lookup itself.

In order to share the retry logic with $graphLookup, we think the best place to implement this would be somewhere inside of attachCursorSourceToPipeline.