Conversation
…gnal testReplaySignal_reusesSameRowAndDoesNotDuplicate waited only for the persisted-signal row to appear before calling replaySignal. A successful signal writes the instance as RUNNING and schedules a re-run that writes it back to WAITING, so the replay raced that re-run's write and failed with OptimisticLockingError. On GitHub-hosted runners the race hit three of eight matrix legs in a day, blocking the jvm-build fan-in on main. expectWorkflowToWait() waits for WAITING and then for the scheduler task to drain, which is exactly the settle the replay needs.
rgamba
marked this pull request as ready for review
September 15, 2026 23:28
rgamba
force-pushed
the
fix-replay-signal-test-race
branch
from
September 15, 2026 23:39
8931d6b to
7171637
Compare
This branch has not been deployed
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
1 participant
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.
Summary
Fixes the flake in
SqliteWorkflowIntegTest > TestPersistedSignals > testReplaySignal_reusesSameRowAndDoesNotDuplicate, which failed withOptimisticLockingErrorat thereplaySignalcall on three of eight JVM matrix legs today, including two of four on the firstmainrun after #28 (run 35024834524). With thejvm-buildfan-in red,tag-releasecannot run.Cause
After a successful signal the engine writes the instance as
RUNNINGand schedules a re-run, which then writes it back toWAITING. The test waited only for the persisted-signal row to exist, which is already true the instant the signal executes, and then calledreplaySignalwhile that re-run was still in flight. Both paths write the instance, and the loser gets the optimistic-locking error. GitHub's runners hit the window far more often than CircleCI's did.Fix
One added wait:
helper.expectWorkflowToWait()between the signal and the replay. It waits forWAITINGand then for the scheduler task to drain, so the replay starts against a settled instance. Test-only change; no production code touched.Testing
SqliteWorkflowIntegTestrun locally with--rerun; the replay test passes (0.2 s) alongside the rest of the class.