-
Type: Bug
-
Resolution: Gone away
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Aggregation Framework
-
Query
-
ALL
After SERVER-32088, the following scenario would incorrectly fail to resume:
1. Create and shard collection through mongos1 (the soon-to-be stale mongos).
2. Drop and recreate the same collection name through mongos2.
3. Open a change stream through mongos2 and obtain a valid resume token.
4. Attempt to resume using the resume token from (3) through mongos1, which is now stale.
--> The mongos will compare it's stale collection's UUID to the UUID in the resume token, and incorrectly assert.
One potential fix is to always perform a hard refresh of the shard registry if we're attempting to resume a change stream, before getting the collection UUID.
- related to
-
SERVER-32088 ChangeStream resumeAfter does not work on sharded collections if not all shards have chunks for the collection
- Closed