[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: |
|
||||||||||||
| 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 |
| 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. |