At present, we uassert if the current UUID of the sharded namespace on which the $changeStream is running differs from the UUID found in the oplog entry, implying that the collection was dropped and resharded before we had a chance to obtain the shard key fields for the documentKey. This prevents $changeStream from returning the remaining oplog entries leading up to the original collection's invalidation.

However, given that:

• We cannot resumeAfter on a dropped collection regardless, so the shard key fields are irrelevant for resume token purposes
• mongoS will not attempt to updateLookup the documentKey if the current UUID does not match the operation UUID and will correctly add fullDocument:null to the $changeStream entry
• Dropping the collection does not uassert; only recreating it prevents $changeStream from continuing

... it should be safe to simply return _id for the documentKey and allow $changeStream to proceed. This would bring sharded $changeStream into alignment with the behaviour on a single replica set, where dropping and recreating a collection in this way does not prevent $changeStream from retrieving the remainder of the old collection's oplog entries.