[SERVER-34432] Allow $changeStream resume attempts to proceed if the initial stream documents have the same clusterTime as the resume token but lower-sorting UUIDs Created: 12/Apr/18 Updated: 29/Oct/23 Resolved: 12/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | None |
| Fix Version/s: | 3.7.4 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Bernard Gorman | Assignee: | Bernard Gorman |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Sprint: | Query 2018-04-23 |
| Participants: |
| Description |
|
When determining whether it is possible to resume a change stream, we currently reject the resume attempt and uassert if a document observed in the stream has the same clusterTime but a different UUID than the resume token. However, in the case of the new whole-database and cluster-wide change streams running on a sharded cluster, this is a legitimate scenario; we may observe operations from multiple shards that occurred at the same time on different namespaces. To ensure correct resume semantics, we should continue to examine subsequent documents in the stream if the current document's UUID sorts before the resume token's, implying that we should expect to see the resume token later. However, if the document's UUID sorts after the resume token's UUID, then we will never see the token and can safely reject the resume attempt. |
| Comments |
| Comment by Githook User [ 12/Apr/18 ] |
|
Author: {'email': 'bernard.gorman@gmail.com', 'name': 'Bernard Gorman', 'username': 'gormanb'}Message: |