-
Notifications
You must be signed in to change notification settings - Fork 207
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
fix: don't assert on unordered publishes after publish error #49
Conversation
(reviewing right now, will merge myself if all is fine and the CI is done by then) |
Thanks Peter! |
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.
The fix works and the code looks good.
Your PR has attempted to merge for 3 hours. Please check that all required checks have passed, you have an automerge label, and that all your reviewers have approved the PR |
2 similar comments
Your PR has attempted to merge for 3 hours. Please check that all required checks have passed, you have an automerge label, and that all your reviewers have approved the PR |
Your PR has attempted to merge for 3 hours. Please check that all required checks have passed, you have an automerge label, and that all your reviewers have approved the PR |
Merge-on-green attempted to merge your PR for 6 hours, but it was not mergeable because either one of your required status checks failed, or one of your required reviews was not approved. Learn more about your required status checks here: https://help.github.com/en/github/administering-a-repository/enabling-required-status-checks. You can remove and reapply the label to re-run the bot. |
Unordered batches that threw errors on invoking the publish RPC led to subsequent assertion failures in thread.py::publish(). These assertion failures were legitimate. Publish calls should not be called on batches that have already been committed. (In this case, they were committed and then returned an error.)
This pull request fixes the underlying issue by clearing out the UnorderedSequencer's _current_batch on commit(). This ensures that no subsequent publish() calls will be called on that batch since the reference to it is lost.
I add a new "test_publish_after_batch_error" test for this scenario.
The OrderedSequencer does not have this issue. On error, it cancels all batches and pauses the ordering key. The existing "test_batch_done_unsuccessfully" test captures this scenario.
Fixes #48