[✨ 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: 87d9df.
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 !_hasWaiter (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=True, Repository=dotnet/runtime)
[Tool] Searching for _hasWaiter WebSockets, WebSockets assertion failed, System.Net.WebSockets.Client.Tests assertion (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=True, Repository=dotnet/runtime)
[Tool] Found 35 issues, 163 comments, 24 returned results (12152 ms)
[Tool] Found 49 issues, 219 comments, 39 returned results (17501 ms)

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

---

1. PR #96653 (Jan 2024) - Move PendingTypeLoadTable from the ClassLoader object to a global structure

• Summary: This PR by davidwrighton introduces sharding and pre-allocation to the PendingTypeLoadTable to reduce lock contention and allocator pressure. The code changes include a new HasWaiters() method and logic involving a _hasWaiter field.
• Relevant Discussion: Reviewer AaronRobinsonMSFT suggested adding an assert in the new HasWaiters() method. There is a suggestion to add an assert for the waiter state, and the code introduces and manipulates a _hasWaiter field, which is directly related to the assertion failure seen in the test.
• Conclusion: This PR is very likely the source of the assertion failure !_hasWaiter in the test, as it introduced new logic and asserts around waiter tracking for type loads.

---

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

• Summary: This PR by CarnaViire fixes a test (ConnectAsync_Http11WithRequestVersionOrHigher_Loopback_Success) that was causing an assert, specifically by skipping the test on platforms that do not support ALPN.
• Relevant Discussion: The PR was created in response to issue #117293, which was about an assert in a WebSocket test. The PR ensures the test is skipped on platforms where it cannot succeed, preventing spurious assertion failures.
• Conclusion: While not directly about _hasWaiter, this PR is an example of recent WebSocket test asserts being triaged and fixed by skipping or adjusting tests.

---

3. Issue #114153 (Apr 2025) - System.Net.WebSockets.Client.Tests timeout

• Summary: This issue, also opened by jkotas, tracks timeouts in the same test suite (System.Net.WebSockets.Client.Tests.WorkItemExecution). The comments note that the underlying problem is likely the same as another issue (#113883) but in a different test, and that a fix was merged in PR #114268.
• Conclusion: This shows a pattern of recent instability or failures in the System.Net.WebSockets.Client.Tests suite, though the specific assertion here is about timeouts, not _hasWaiter.

---

4. Issue #119520 (Sep 2025) - System.Net.WebSockets.Client.Tests android fails

• Summary: This issue tracks failures in the same test suite on Android, with a different error message but similar context (test infrastructure, timeouts, or command exit codes).
• Conclusion: Indicates ongoing test infrastructure or platform-specific issues in the same area.

---

5. Issue #22604 (July 2017) - 'System.Net.WebSockets.Client.Tests' failed in CI

• Summary: An older issue tracking failures in the same test suite, but resolved as "already fixed" and not related to the _hasWaiter assertion.
• Conclusion: Not directly relevant to the current assertion, but shows the long history of test flakiness in this area.

---

Summary of Findings

• Root Cause: The assertion !_hasWaiter was introduced as part of the PendingTypeLoadTable refactoring in PR #96653. The new logic tracks waiter state for type loads and asserts that no waiter is present at certain points. The assertion failure in System.Net.WebSockets.Client.Tests.WorkItemExecution is likely a result of this new logic.
• Recent Related Fixes: There have been other recent PRs and issues addressing assertion failures in WebSocket tests, such as PR #117507, but those are not about _hasWaiter.
• Test Suite Instability: There is a pattern of recent failures and timeouts in System.Net.WebSockets.Client.Tests, but the _hasWaiter assertion is new and directly tied to the type loader changes.

---

Recommendation

• Immediate Action: The assertion failure should be investigated in the context of the PendingTypeLoadTable changes from PR #96653. The test failure may indicate a bug in the new waiter tracking logic or a test that triggers an unexpected type load pattern.
• Related Areas: If you are triaging this issue, it would be useful to tag it as related to the type loader refactoring and possibly assign to the author or reviewers of PR #96653 for further investigation.

---

If you need further details on the specific code or want to see the full comment history of PR #96653, let me know!