-
Notifications
You must be signed in to change notification settings - Fork 15
REP-5299 Finalize change stream with a timestamp. #47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
REP-5299 Finalize change stream with a timestamp. #47
Conversation
|
@tdq45gj and @mmcclimon: I’ve made several updates to this PR that ideally should get a re-review before merge, but to ensure MV’s availability for MF testing on Friday (in EMEA) I’m going to proceed with the merge. For posterity: I spent a good while trying to make TestGenerationalRechecking work as it is. I kept getting inconsistent results from the very last bit where it calls WritesOff then alters the server. I eventually concluded that this test is invalid because altering the server right after WritesOff is nonsense, which means expectations of a consistent response to it are unfounded. Thus, I’ve removed that part of the test. I think commit 79d5675 is where you both last approved this. Since then:
|
| // This has to happen under the lock because the change stream | ||
| // might be inserting docs into the recheck queue, which happens | ||
| // under the lock. | ||
| verifier.changeStreamWritesOffTsChan <- finalTs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does sending finalTs need to be under the lock? We unlocked on L256 but this comment says this has to happen under the lock.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oof, a mis-worded comment. It should read “This has to happen outside the lock …”
Previously to finalize its change stream the verifier would just TryNext() until no responses arrived. This works fine for unsharded clusters, but for sharded clusters it can potentially miss events.
This changeset adopts more “tried-and-true” logic: grab a timestamp via
appendOplogNote, then iterate the change stream until the stream’s resume token’s timestamp meets or exceeds that timestamp. As verification of that change, this changeset removes the test skips that REP-5306 (PR #48) imposed for sharded clusters.The timestamp-grabbing logic is unconditionally retryable, which requires an update to the retryer module to implement. This changeset refactors that module a bit to prevent further duplication.
Additional changes: