Repository navigation
test-quic-writer-stop-sending is flaky (for me) #63309
Description
Activity
Hello @Renegade334
I’d like to investigate this.
From the report, it looks like the test currently depends on a fixed 100ms delay for the stream state transition to propagate, which may be too timing-sensitive across different systems/CI environments.
I’ll inspect
test-quic-writer-stop-sending.mjsto understand which async state transition the assertion is waiting on and whether the test can be synchronized on a deterministic event/state change instead of relying on a fixed timeout.Reproducing the Issue
I can reproduce this failure 100% of the time on Linux x86_64 (Ubuntu 24.04, Node v27.0.0-pre, gcc 13.3.0). The root cause is a race condition the 100ms
setTimeoutat line 54 is not sufficient for the stream's stop-sending state to propagate through the QUIC layer before the assertion fires.Proposed Fix
Rather than increasing the hardcoded timeout (which is fragile and machine-dependent), I'd suggest replacing the timer-based check with an event-driven approach i.e., listen for the appropriate stream or session event that confirms the stop-sending state has actually been applied, and only assert inside that callback.
This is more robust because:
- It doesn't rely on arbitrary timing
- It won't flake on slow CI machines or under load
- It follows the pattern used in other QUIC tests
As a short-term workaround, bumping the timeout to 1000ms appears to stabilize things, but that's a band-aid rather than a real fix.
Happy to open a PR with the event-driven approach if that direction looks good to the
@nodejs/quicteam.This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.Pretty sure this was caused by #64710, and is now resolved.
The flaky test itself is gone in any case, and the fixed issue there (stop sending callbacks firing incorrectly, not connected to the inbound network traffic they were intended to track) completely explains the failure to propagate within the timeout. All the replacement tests seem stable to me now. I'm going to close this as fixed.
Reacted by René
Test
test-quic-writer-stop-sending
Platform
Linux x64
Console output
Build links
Additional information
On my system, the timeout of 100ms is insufficient for the stream state to propagate, and this assertion fails ~100% of the time. Extending the timeout arbitrarily to 1000ms appears to settle things.
cc: @nodejs/quic