[SERVER-35254] Resuming a change stream on a stale mongos with a valid resume token may incorrectly fail Created: 25/May/18  Updated: 27/Oct/23  Resolved: 17/May/20

Status: Closed
Project: Core Server
Component/s: Aggregation Framework
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Nicholas Zolnierz Assignee: Backlog - Query Team (Inactive)
Resolution: Gone away Votes: 0
Labels: query-44-grooming
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-32088 ChangeStream resumeAfter does not wor... Closed
Assigned Teams:
Query
Operating System: ALL
Participants:

 Description   

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.



 Comments   
Comment by Bernard Gorman [ 17/May/20 ]

This is no longer an issue. The explicit UUID check was performed only to determine whether we could correctly inherit the collection's default collation. As of SERVER-39302, we no longer inherit the collation and so this check is no longer necessary.

Generated at Thu Feb 08 04:39:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.