Skip to content

p2p: fix flaky TestWithReceiveTimeout on QUIC#4606

Merged
pinebit merged 1 commit into
mainfrom
pinebit/fix-flaky-receive-timeout-test
Jul 27, 2026
Merged

p2p: fix flaky TestWithReceiveTimeout on QUIC#4606
pinebit merged 1 commit into
mainfrom
pinebit/fix-flaky-receive-timeout-test

Conversation

@pinebit

@pinebit pinebit commented Jul 27, 2026

Copy link
Copy Markdown
Collaborator

TestWithReceiveTimeout fails intermittently in CI on the QUIC iteration:

--- FAIL: TestWithReceiveTimeout (0.47s)
    Error: Error "write request: stream reset (remote): code: 0x0: transport error:
           stream 4 canceled by remote with error code 0" does not contain "read response: EOF"

The test registers the server handler with WithReceiveTimeout(0), so the read deadline in p2p/receive.go is already expired when the handler starts. ReadMsg fails instantly and the deferred s.Close() tears the stream down — the CI log shows this happening 101µs in. Meanwhile the client is still in WriteMsg. Nothing synchronises the two, so which call reports the failure depends on who wins the race.

The transport decides the usual winner. The test loops over both:

  • TCP/yamuxClose() is a graceful FIN. The in-flight write is absorbed by the buffer and succeeds, so the failure surfaces at the read as EOF. Deterministic.
  • QUICClose() with unread incoming data emits STOP_SENDING/RESET_STREAM. If that lands mid-write, WriteMsg fails first and the read is never reached.

The assertion only allowed the first outcome, so a loaded runner could flip it. This is the same class of QUIC behaviour sender.go already tolerates via isCanceledStreamErr, whose comment notes these errors appear "much more frequently when QUIC is enabled" — that handling just does not extend to WriteMsg.

This accepts either terminal error on the QUIC iteration. The TCP iteration stays strict, since it has no race, and an unrelated error still fails on both.

category: test
ticket: none

The zero receive timeout makes the server close the stream almost immediately,
racing the client's request write. On TCP the close is a graceful FIN, so the
write always lands and the failure surfaces as an EOF on the response read. QUIC
instead resets the stream, which can abort the write already in flight, failing
with "write request: stream reset (remote)" before the read is ever reached.

Accept either error on the QUIC iteration. The TCP iteration stays strict.

category: test
ticket: none

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@pinebit
pinebit requested a review from KaloyanTanev July 27, 2026 13:25
@sonarqubecloud

Copy link
Copy Markdown

@codecov

codecov Bot commented Jul 27, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 57.55%. Comparing base (2eb6798) to head (5a8886a).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4606      +/-   ##
==========================================
- Coverage   57.58%   57.55%   -0.03%     
==========================================
  Files         246      246              
  Lines       33675    33675              
==========================================
- Hits        19392    19383       -9     
- Misses      11845    11850       +5     
- Partials     2438     2442       +4     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@pinebit
pinebit merged commit adddef7 into main Jul 27, 2026
13 checks passed
@pinebit
pinebit deleted the pinebit/fix-flaky-receive-timeout-test branch July 27, 2026 14:14
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.

2 participants