[SERVER-30590] Don't allow resuming changeStreams after sharded collection drop Created: 10/Aug/17  Updated: 27/Oct/23  Resolved: 20/Oct/17

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

Type: Task Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Nathan Myers
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-30579 Change resumeTokens to include collec... Closed
related to SERVER-30599 Get shard key into documentKey and re... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2017-09-11, Repl 2017-10-02, Repl 2017-10-23
Participants:

 Description   

Once a collection is dropped we lose all catalog information about it, which makes it impossible to extract the shard key on new cursors on sharded collections. So that means that resuming a sharded change stream after the collection was dropped won't work. We should make sure that fails gracefully.



 Comments   
Comment by Nathan Myers [ 20/Oct/17 ]

Are we agreed that this ticket is resolved by clarifications of the spec?

Comment by Spencer Brody (Inactive) [ 10/Aug/17 ]

I updated the description to clarify that the real issue is with sharded cursors. So long as we can make the sharded cursor behavior correct, then we don't need to do anything to mongod behavior. We'll only change the mongod behavior if it's required to properly detect collection drops in sharded changestreams.

Comment by Siyuan Zhou [ 10/Aug/17 ]

Is this a dup of SERVER-29140? We make the decision purely based on the oplog entries. Catalog is not considered here. Did I miss anything?

Comment by Spencer Brody (Inactive) [ 10/Aug/17 ]

This can probably work by double-checking the existence of a collection with the correct UUID before generating each new notification, and if the UUID no longer exists returning an 'invalidate' entry instead of whatever would have otherwise been returned.

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