-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 3.6.0-rc2
-
Component/s: Aggregation Framework
-
None
-
Fully Compatible
-
Query 2018-05-07
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:
- We cannot resumeAfter on a dropped collection regardless, so the shard key fields are irrelevant for resume token purposes
- mongoS will not attempt to updateLookup the documentKey if the current UUID does not match the operation UUID and will correctly add fullDocument:null to the $changeStream entry
- Dropping the collection does not uassert; only recreating it prevents $changeStream from continuing
... 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.
- is related to
-
SERVER-31691 Change streams UUID mismatch uasserts with error code that causes invariant
- Closed
- related to
-
SERVER-29134 Support returning all change notifications for a database in a sharded cluster
- Closed