Skip to content

test(state): fix apply-barrier race in MultiProcessIpc.BidirectionalReplication - #543

Merged
transfix merged 1 commit into
masterfrom
fix/multiprocess-ipc-replication-flake
Oct 2, 2026
Merged

transfix merged 1 commit into
masterfrom
fix/multiprocess-ipc-replication-flake

Conversation

@transfix

@transfix transfix commented Oct 2, 2026

Copy link
Copy Markdown
Owner

Fixes the intermittent MultiProcessIpcIntegration.BidirectionalReplication failure (child exits 12, "did not receive server's value") that surfaces in the recipe lane (which runs the Integration tests).

Root cause (apply-barrier race): the test used wait_for_received(1) as the sync point before reading the replicated value from the tree. But wait_for_received counts frames decoded by the reader thread, not frames applied to the tree — and inbound frames are ingested on pump_all(). So the child checked server_val == "from_server" while only an earlier frame (or nothing) had been applied, captured a stale value, and exited 12. The for(40) pump loop that actually applies the frames ran after the check. The parent's got_client check had the identical latent race.

Fix: on both sides, poll the actual condition — pumping (pump_all/flush) so received frames are applied — until the expected value appears or a 5s deadline passes, instead of trusting the frame-decode counter.

Verified: 100/100 runs of BidirectionalReplication pass (it reproduced ~1-2/20 before). Test-only; no product code changed.

…eplication

The test used wait_for_received(1) as the sync point before reading the replicated
value from the tree. But wait_for_received counts frames DECODED by the reader
thread, not frames APPLIED to the tree, and inbound frames are ingested on
pump_all(). So the child checked `server_val == "from_server"` while only an earlier
frame (or nothing) had been applied, captured a stale value, and exited 12 ("child
did not receive server's value") — intermittently (~2/20 locally; it surfaced in the
recipe lane). The parent's `got_client` check had the identical latent race.

Fix: on both sides, poll the ACTUAL condition — pumping (pump_all/flush) so received
frames are applied — until the expected value appears or a 5s deadline passes,
instead of trusting the frame-decode counter. No product code changed.

Verified: 100/100 runs of BidirectionalReplication pass.
@transfix
transfix enabled auto-merge October 2, 2026 17:09
@transfix
transfix merged commit 108b806 into master Oct 2, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant