[SERVER-31847] Allow sharded $changeStream to continue if collection is dropped and resharded before documentKey is obtained Created: 06/Nov/17 Updated: 30/Oct/23 Resolved: 12/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | 3.6.0-rc2 |
| Fix Version/s: | 3.7.4 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Bernard Gorman | Assignee: | Nicholas Zolnierz |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Query 2018-05-07 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
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:
... 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. |
| Comments |
| Comment by Asya Kamsky [ 24/Mar/18 ] |
|
This is different than the use case of collection becoming sharded (having previously been watched when it was unsharded). That one might be |
| Comment by Asya Kamsky [ 24/Mar/18 ] |
|
I agree that it should continue until it gets to the drop in the oplog at which point it will invalidate the change stream (right?) |
| Comment by Charlie Swanson [ 12/Mar/18 ] |
|
Bumping this out of the sprint in favor of SERVER-32283 |