[SERVER-57792] Always supply invalidate event to DSCSEnsureResumeTokenPresent when starting after an invalidate Created: 17/Jun/21  Updated: 29/Oct/23  Resolved: 12/Jul/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 5.1.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Bernard Gorman Assignee: Denis Grebennicov
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Query Execution 2021-06-28, Query Execution 2021-07-12, Query Execution 2021-07-26
Participants:

 Description   

With change stream optimization enabled, if we push down a $match that filters out an invalidate message from the stream, we still ensure that the stream is invalidated via our new ChangeStreamInvalidation exception. But we also provide the invalidate resume token as the final PBRT to the client, so they can optionally use it with startAfter to restart the stream after the invalidation. But in this case, even if they restart the stream with the exact same pipeline, DSCSEnsureResumeTokenPresent will fail to see the token in the resumed stream and will throw.

We should make sure that we support resuming in all cases where the resume pipeline is identical to the original pipeline, including the case of startAfter with an invalidate token.



 Comments   
Comment by Vivian Ge (Inactive) [ 06/Oct/21 ]

Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you!

Comment by Githook User [ 12/Jul/21 ]

Author:

{'name': 'Denis Grebennicov', 'email': 'denis.grebennicov@mongodb.com', 'username': 'denis631'}

Message: SERVER-57792 Always supply invalidate event to DSCSEnsureResumeTokenPresent when starting after an invalidate
Branch: master
https://github.com/mongodb/mongo/commit/574a5fea4d4f34b15e7519ba778776c6fc5d19d3

Generated at Thu Feb 08 05:42:48 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.