-
Type: Bug
-
Resolution: Unresolved
-
Priority: Minor - P4
-
None
-
Affects Version/s: None
-
Component/s: Aggregation Framework
-
Query Execution
-
ALL
In a sharded cluster it may be possible for two database drops to happen on two different shards at the same time. Since a database does not have a UUID or a documentKey, the resume token for the drop will simply contain a timestamp. This means that is possible for two distinct changes to have the same resume token.
A database drop will invalidate the stream, so this likely isn't an issue, but if we allow an actual notification of this event without an invalidation, then a client who tries to resume with one of the two identical resume tokens might see a drop twice or not at all.
- related to
-
SERVER-34932 [change streams] Adjust resume token (if necessary) for sharded transactions
- Closed
-
SERVER-90266 Rename collection events do not have total ordering in change streams
- Backlog
-
SERVER-42008 Simultaneous sharded collection drops do not have a total ordering in change streams
- Backlog
-
SERVER-90023 dropIndexes events do not have total ordering in change streams
- Backlog