[✨ Triage] dotnet/runtime#125806 by danmoseley - RequestSendingResponseDisposed_ThrowsOnServer fails with Stream abo ...

[MihuBot]

Triage for dotnet/runtime#125806.
Repo filter: All networking issues.
MihuBot version: 246635.
Ping MihaZupan for any issues.

This is a test triage report generated by AI, aimed at helping the triage team quickly identify past issues/PRs that may be related.
Take any conclusions with a large grain of salt.

Tool logs

dotnet/runtime#125806: RequestSendingResponseDisposed_ThrowsOnServer fails with Stream aborted by peer by danmoseley
Extracted 5 search queries: RequestSendingResponseDisposed_ThrowsOnServer test failing "Stream aborted by peer", HttpClientHandlerTest_Http3 "Stream aborted by peer", HttpClientHandler RequestSendingResponseDisposed Http/3 server disposes response aborts stream, "Stream aborted by peer" Quic/HTTP3 connection aborted in functional tests, Flaky System.Net.Http functional tests Http3 RequestSendingResponseDisposed CI failure
Found 25 candidate issues

• Issue #103264 (June 2024) - "[8.0] "Stream aborted by peer" failure in System.Net.Http.Functional.Tests.HttpClientHandlerTest_Http3.ServerSendsTrailingHeaders_Success"
  Summary: CI hit showing "Stream aborted by peer" in an Http3 functional test (ServerSendsTrailingHeaders_Success). Triagers concluded this looks like the same flake tracked by older issue #87552; the behavior appears limited to 8.0 (9.0+ is fine after earlier fixes) and the pragmatic result was to stop tracking it for mainline and to disable on 8.0. This shows the pattern: similar HTTP/3 stream-abort flakes can persist intermittently even after fixes.

• Issue #98786 (Feb 2024) - "[QUIC][8.0] System.Net.Http.Functional.Tests.HttpClientHandlerTest_Http3.ServerSendsTrailingHeaders_Success Stream aborted by peer (268)"
  Summary: Another instance of the same ServerSendsTrailingHeaders_Success failure in 8.0 CI. Discussion: low-frequency flake with many reruns; tied back to the same underlying intermittent quic/http3 races (closed as dupe of #87552). Shows repeated CI occurrences and attention to backports but eventual decision to treat as release-branch-only flakiness.

• Issue #87814 (June 2023) - "[Test Failure] System.Net.Http.Functional.Tests.HttpClientHandlerTest_Http3.ServerSendsTrailingHeaders_Success"
  Summary: Early reporting of the same flaky test (passes on rerun). Closed as duplicate of the long-running #87552. Reinforces that this test/behavior has been historically flaky and repeatedly triaged as part of the same class of HTTP/3 QUIC races.

• PR #57156 (Aug 2021) - "[HTTP/3] Abort response stream on dispose if content not finished" (merged)
  Summary: Implemented logic to send QUIC aborts when a response stream is disposed before its content is finished. This was intended to fix cases where server doesn't observe client cancellation (client disposed response but server saw EOF instead of abort). Merged and backported; it fixed some scenarios but subsequent issues show more races remained (e.g., when finalization or other timing variants occur).

• Issue #56129 (July 2021) - "[HTTP/3] Cancellation of response download not reported correctly on server"
  Summary: Root report that disposing the HttpResponseMessage / cancelling the response wasn't reliably causing an abort visible to server; server sometimes saw EOF (graceful close) instead of abort. That prompted the PR above (#57156) and further follow-ups. The original problem and its partial fixes are directly relevant to "RequestSendingResponseDisposed_ThrowsOnServer" failing with "Stream aborted by peer".

• PR #72670 (July 2022) - "Remove Http3RequestStream from _activeRequest when response is read/aborted." (merged)
  Summary: Ensures Http3 request streams are removed from _activeRequests immediately after the request is read/aborted (not only when response Stream.Dispose is called). This reduces hangs and enables closing connections earlier; it addressed a class of timing issues where a response being left undisposed blocked connection shutdown.

• PR #90659 (Aug 2023) - "[HTTP/3] Release the stream once the response is sent" (merged)
  Summary: Further HTTP/3 changes to release internal stream state right after response is sent; intended to reduce lifetime/race issues when response completes but user code hasn't disposed yet. Helpful mitigation for tests that depend on timely teardown.

• Issue #58072 (Aug 2021) - "HTTP3: Http3Stream is not removed from _activeRequests table until response Stream Dispose is called"
  Summary: Tracked the problem that streams were retained in internal tables until final Dispose, which could delay connection shutdown or cause races. Led to later PRs (e.g., #72670) to remove streams earlier. Shows relevant lifecycle/race context for "disposed response" test failures.

• Issue #72619 (July 2022) - "[HTTP/3] Stress test failures for GET Aborted scenario"
  Summary: Large number of stress failures where server didn't see aborts or client observed unexpected behavior. Investigation showed an aspnetcore change exposed races; fixes on the Kestrel side (aspnetcore PRs) resolved the stress failures. Demonstrates that interactions across layers (Kestrel, S.N.Http, S.N.Quic / msquic) can produce these intermittent stream-abort symptoms.

• Issue #69481 (May 2022) - "MsQuicStream may throw QuicOperationAbortedException when connection is closed by peer"
  Summary: Found a race where msquic could return an "aborted" status from a Send call before the connection-shutdown event was delivered to the app thread; the runtime code could therefore misclassify the error (operation aborted vs connection-aborted) and throw QuicOperationAbortedException. MsQuic team was asked to consider fixes; triagers concluded this is a msquic/API-level race to be handled either by msquic or by runtime workarounds. This is relevant because similar msquic timing races produce "Stream aborted by peer" and other flaky test outcomes.

• Issue #67476 (Apr 2022) - "Quic tests failing with Error Code: ... Stream aborted by peer"
  Summary: Early cluster of QUIC test failures showing "Stream aborted by peer" across multiple tests; pointed to msquic/QUIC layer timing and interaction issues. Triaged as Quic-area problem.

• Issue #41337 (Aug 2020) - "QUIC/HTTP3 request stream read failures" (fixed)
  Summary: Historic investigation into reads appearing to shutdown rather than throw; fix (#42315) resolved some earlier control-frame/SETTINGS bugs. Demonstrates long history of QUIC/HTTP3 flakiness and iterative fixes.

• Issue #100534 (Apr 2024) - "[HTTP/3] [HttpStress] QuicException: Stream aborted by peer (258) in (POST Duplex | PUT) Slow"
  Summary: High-volume HttpStress hits producing stream-aborted errors (various error codes). Considered likely to share root causes (msquic timing/races) with other flaky HTTP/3 tests; later closed as covered by other tracking issues. Reinforces that stress/hard timing runs expose abort races.

• Issue #92390 (Sep 2023) - "HTTP/3: Hang when reading content or disposing response when SerializeToStreamAsync doesn't complete"
  Summary: Describes a hang where server-side SerializeToStreamAsync never completes and that causes client-side hangs when finishing the response or disposing. Shows another class of race between request content serialization, response completion, and disposal that can produce test hangs or aborts.

• Issue #60141 (Oct 2021) - "[HTTP/3] Http3RequestStream is not properly aborted on finalization"
  Summary: Finalizer semantics were missing for Http3RequestStream, so finalized but not explicitly disposed streams resulted in graceful close instead of Abort; this could lead to corrupted behavior and intermittent failures. Led to fixes to ensure aborting on finalization where appropriate.

• Issue #84767 (Apr 2023) - "System.Net.Http.Functional.Tests failure" (Http2 assertion about calling after disposing)
  Summary: Although focused on HTTP/2, this discussion illustrates a general class of races where dispose/shutdown signaling and connection-pool removal race and can cause assertions or crashes. Useful context: there are similar races across HTTP/2/HTTP/3 around disposal vs pool lifecycle.

• Issue #117484 (July 2025) - "CI failure ... MaxResponseHeadersLength Http3.ThresholdExceeded_ThrowsException"
  Summary: Newer example of HTTP/3 functional tests failing with other HTTP/3 protocol errors (connection closed / H3_NO_ERROR). Shows the ongoing presence of HTTP/3 test flakes across different scenarios and that CI continues to surface varied HTTP/3 failures.

Takeaways for triage of the new failure (RequestSendingResponseDisposed_ThrowsOnServer - Stream aborted by peer)

• This new failure fits a well-known pattern: HTTP/3 tests intermittently seeing "Stream aborted by peer" when response streams are disposed or when client cancels/aborts. The area has had numerous fixes (e.g., abort-on-dispose in #57156, releasing streams earlier in #72670/#90659), but timing races remain (often exposed on particular branches, stress runs, or older release branches).
• There are two broad root classes seen historically:
  1. HTTP/3 / SocketsHttpHandler lifecycle races (response disposed vs request/response state) → mitigations in Http3RequestStream/Http3Connection (PRs cited).
  2. msquic / QUIC timing races where Send/Abort/connection-shutdown ordering causes the runtime to see an aborted send before the connection/shutdown event is delivered → sometimes requires msquic-side work or careful handling in MsQuicStream code (#69481, #52776).
• Practical triage guidance (from past practice): check whether the failure is limited to a branch (8.0) or appears on main; try rerunning (many of these are flaky and pass on rerun); verify whether recent PRs touching HTTP/3/Quic or msquic version updates were in the PR/merge (these often coincide with new flakes); consider marking as known build error / disable on release branch if repro is rare and fixes are already in newer branches.

If you want, I can:

• correlate the failing job's exact logs (helix console) to determine whether this run exhibited a known pattern (e.g., PEER_RECEIVE_ABORTED vs SEND_COMPLETE with Canceled=true vs INVALID_STATE), or
• suggest a short checklist of runtime/msquic/aspnetcore PRs to inspect for the PR that triggered the CI run.