-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Aggregation Framework
-
None
-
Fully Compatible
-
ALL
-
Query 2018-04-09
It's possible for a collection to be sharded for some period of time before the shard knows that the collection is sharded. Because of this, it's possible for insert notifications to be generated without the shard key for a period of time after the collection has been sharded.
When the change stream is resumed, it might be resuming on one of these changes, at a future point when the shard knows that the collection is sharded. When this happens, the resume token will not include the full shard key in the documentKey, but the new generated change which we compare the resume token to will. We should allow resuming in this case if the _ids match. This is safe because there must not have been any chunk migrations up until this point (or the shard would have known the collection was sharded, generating shard keys in the documentKey), so the _id should still be unique.
- related to
-
SERVER-32085 $changeStream reports incorrect documentKey for unsharded collections that become sharded
- Closed