fix: relax exact-batch-count assertions in interrupt/resume tests#432
Merged
driv3r merged 1 commit intoApr 15, 2026
Merged
Conversation
austenLacy
approved these changes
Apr 15, 2026
austenLacy
left a comment
austenLacy
left a comment
There was a problem hiding this comment.
Maybe good to add to the comment why the subsequent ID assertions make a >200 count OK.
driv3r
force-pushed
the
get-rid-of-vendored-packages
branch
from
3cd3fd2 to
fb0ca17
Compare
driv3r
force-pushed
the
fix-flaky-interrupt-resume-test
branch
from
ef4568c to
f97faf3
Compare
TERM is delivered asynchronously via Go's signal channel. The signal
handler calls ErrorHandler.Fatal which panics, but there is a race window
between send_signal("TERM") returning in the Ruby callback and the
signal actually interrupting the data iterator goroutine. A second 200-row
batch can complete before the panic propagates, causing the target row
count to be 400 instead of the asserted 200.
The real correctness invariant is already checked by the subsequent
assertions: last_successful_id from the target matches the pagination key
in the dumped state. The exact count check adds no additional safety and
only makes the tests fragile. Relax both the integer-keyed and UUID-keyed
variants to assert_operator :>= 200.
driv3r
force-pushed
the
fix-flaky-interrupt-resume-test
branch
from
f97faf3 to
e404408
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TERM is delivered asynchronously via Go's signal channel. The signal handler calls ErrorHandler.Fatal which panics, but there is a race window between send_signal("TERM") returning in the Ruby callback and the signal actually interrupting the data iterator goroutine. A second 200-row batch can complete before the panic propagates, causing the target row count to be 400 instead of the asserted 200.
The real correctness invariant is already checked by the subsequent assertions: last_successful_id from the target matches the pagination key in the dumped state. The exact count check adds no additional safety and only makes the tests fragile. Relax both the integer-keyed and UUID-keyed variants to assert_operator :>= 200.