[✨ Triage] dotnet/runtime#121157 by jkotas - System.Net.WebSockets.Client.Tests: Assertion failed: !_hasWaiter

[MihuBot]

Triage for dotnet/runtime#121157.
Repo filter: All networking issues.
MihuBot version: fe265e.
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#121157: System.Net.WebSockets.Client.Tests: Assertion failed: !_hasWaiter by jkotas
[Tool] Searching for Assertion failed !_hasWaiter, System.Net.WebSockets.Client.Tests.WorkItemExecution, WebSockets assertion !_hasWaiter (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=True, Repository=dotnet/runtime)
[Tool] Found 24 issues, 7 comments (39140 ms)

Here are related issues and discussions for triaging issue #121157 ("System.Net.WebSockets.Client.Tests: Assertion failed: !_hasWaiter"):

---

Directly Related Issues

Issue #121157 (Oct 2025) - System.Net.WebSockets.Client.Tests: Assertion failed: !_hasWaiter

• Summary: Test failure in System.Net.WebSockets.Client.Tests.WorkItemExecution with assertion !_hasWaiter failing. The stacktrace shows the failure occurs in System.Net.Http.Http2Connection.Http2Stream.TryReadFromBuffer, called from ManagedWebSocket.WaitForServerToCloseConnectionAsync and SendCloseFrameAsync.
• Comments: The only comment provides the full stacktrace, confirming the assertion is in the HTTP/2 stream code, triggered during WebSocket close operations.

---

Other Issues with Similar Symptoms or Context

Issue #72301 (July 2022) - WebSockets over HTTP/2 issues

• Summary: Problems with WebSockets over HTTP/2, including server-side stream resets and exceptions in Http2Stream.TryReadFromBuffer. The stacktrace in this issue is similar to #121157, indicating that HTTP/2 stream handling in WebSockets can result in assertion failures or protocol errors.
• Resolution: The issue discusses the need for correct handling of HTTP/2 stream states and flags, especially for CONNECT requests. No direct fix for the assertion, but highlights the fragility of this code path.

PR #70895 (June 2022) - Implement HTTP/2 WebSockets

• Summary: Introduced support for WebSockets over HTTP/2. Comments discuss race conditions and the need to wait for server settings before sending requests, which could relate to the assertion seen in #121157.
• Comments: Team members warn about possible race conditions and disposal issues, which may contribute to assertion failures.

Issue #29294 (Apr 2019) - Failing ManagedWebSocket assert breaking HttpListener tests

• Summary: ManagedWebSocket asserts (though not specifically !_hasWaiter) breaking tests, with stacktraces involving SendCloseFrameAsync and WaitForServerToCloseConnectionAsync. The context is similar: asserts triggered during close operations in ManagedWebSocket.
• Resolution: The issue was fixed, but the general pattern of asserts in ManagedWebSocket close logic is longstanding.

PR #117507 (July 2025) - Fix WebSocket test causing assert

• Summary: Fixes a test that caused an assert in WebSocket code, though not specifically the !_hasWaiter assertion. Indicates recent work in the area of WebSocket test reliability and asserts.

---

Other WebSocket Client Test Issues (Timeouts, State, Threading, etc.)

• Issue #114153 (Apr 2025) - System.Net.WebSockets.Client.Tests timeout: Timeouts in the same test suite, but not assertion failures.
• Issue #112385 (Feb 2025) - MT-System.Net.WebSockets.Client.Tests' END OF WORK ITEM LOG: Command timed out, and was killed: Timeouts in multi-threaded WASM runs.
• Issue #43157 (Oct 2020) - WebSockets won't close properly on Linux: WebSocket close issues, but not assertion failures.
• Issue #110496 (Dec 2024) - ClientWebSocket ReceiveAsync infinite await: Hanging receives, not assertion failures.
• Issue #99545 (Mar 2024) - [browser][ws] WebSocket works differently depending on if we look up its state or not: State propagation issues, not assertion failures.

---

Summary

• The assertion !_hasWaiter in Http2Stream.TryReadFromBuffer is most closely related to the handling of HTTP/2 streams in WebSockets, especially during close operations.
• Issue #72301 and PR #70895 provide context for HTTP/2 WebSocket implementation and known fragility/race conditions in this area.
• Issue #29294 shows that ManagedWebSocket asserts during close have been a recurring problem, though the specific assertion may differ.
• There is no evidence of a direct, previously fixed bug for the exact !_hasWaiter assertion, but the surrounding code and test failures are known to be sensitive to race conditions and state management.
• Recent fixes (PR #117507) indicate ongoing work to improve WebSocket test reliability.

---

Recommended Next Steps

• Review the HTTP/2 WebSocket implementation for race conditions and state transitions, especially in close logic.
• Cross-reference the stacktrace in #121157 with the code changes and discussions in #72301 and PR #70895.
• Consider whether recent changes (PR #117507) may have impacted the area, or if further investigation into race conditions is needed.

---

Related Issues and PRs

• Issue #72301 (July 2022) - WebSockets over HTTP/2 issues
• PR #70895 (June 2022) - Implement HTTP/2 WebSockets
• Issue #29294 (Apr 2019) - Failing ManagedWebSocket assert breaking HttpListener tests
• PR #117507 (July 2025) - Fix WebSocket test causing assert

If you need more details on any specific issue or PR, let me know!