fix: don't assert on unordered publishes after publish error - #49
Conversation
googlebot
added
the
cla: yes
pradn
changed the title
pradn
added
the
automerge
plamut
removed
the
automerge
|
(reviewing right now, will merge myself if all is fine and the CI is done by then) |
Thanks Peter! |
plamut
added
automerge
yoshi-kokoro
removed
the
kokoro:force-run
|
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. |
5 participants
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