[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:
Related
related to SERVER-29134 Support returning all change notifica... Closed
is related to SERVER-31691 Change streams UUID mismatch uasserts... Closed
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 SERVER-32088 I think.

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

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