[test-quarantine] Re-quarantine TestServerTests.WebSocketsWorks (#65914) - #67576
Closed
github-actions[bot] wants to merge 1 commit into
Closed
[test-quarantine] Re-quarantine TestServerTests.WebSocketsWorks (#65914)#67576github-actions[bot] wants to merge 1 commit into
github-actions[bot] wants to merge 1 commit into
Conversation
Test is failing again after being unquarantined in #67261. Failures observed in 3 builds on main branch (Jun 22-23, 2026). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
github-actions
Bot
requested review from
BrennanConroy and
halter73
as code owners
July 3, 2026 11:31
wtgodbe
requested changes
Jul 4, 2026
wtgodbe
left a comment
wtgodbe
left a comment
Member
There was a problem hiding this comment.
Don't merge, the test may have been fixed around June 23. I'll investigate why the workflow didn't skip this on Monday
wtgodbe
added a commit
to wtgodbe/aspnetcore
that referenced
this pull request
Jul 6, 2026
…ected actions Two recent misbehaviors (run 28656097334): PR dotnet#67577 tried to unquarantine SetsTlsHandshakeFeatureForHttps despite issue dotnet#49306 carrying the re-quarantine label, and PR dotnet#67576 re-quarantined WebSocketsWorks despite maintainer "do not quarantine" comments on the already-rejected dotnet#67443/dotnet#67415. Root causes: - The unquarantine re-quarantine check only parsed merged-PR diffs and left the match/exclude decision to the model; it never consulted the re-quarantine issue label the maintainer set. - The closed-PR comment check relied on MCP search_pull_requests, whose DIFC filter silently drops the workflow's own app/github-actions-authored PRs, so the maintainer comments were never seen. Fixes (deterministic pre-activation steps + injected data): - Fetch re-quarantine issue numbers; block unquarantine of any test whose tracking issue is labeled re-quarantine (authoritative, exact match). - Fetch closed-but-unmerged [test-quarantine] PRs + comments with a full token, bypassing the DIFC filter; the closed-PR check now uses this instead of MCP. Recompiled lockfile with gh-aw CLI v0.81.6 (setup action v0.80.9 -> v0.81.6). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
wtgodbe
added a commit
to wtgodbe/aspnetcore
that referenced
this pull request
Jul 6, 2026
…ected actions Two recent misbehaviors (run 28656097334): PR dotnet#67577 tried to unquarantine SetsTlsHandshakeFeatureForHttps despite issue dotnet#49306 carrying the re-quarantine label, and PR dotnet#67576 re-quarantined WebSocketsWorks despite maintainer "do not quarantine" comments on the already-rejected dotnet#67443/dotnet#67415. Root causes: - The unquarantine re-quarantine check only parsed merged-PR diffs and left the match/exclude decision to the model; it never consulted the re-quarantine issue label the maintainer set. - The closed-PR comment check relied on MCP search_pull_requests, whose DIFC filter silently drops the workflow's own app/github-actions-authored PRs, so the maintainer comments were never seen. Fixes (deterministic pre-activation steps + injected data): - Fetch re-quarantine issue numbers; block unquarantine of any test whose tracking issue is labeled re-quarantine (authoritative, exact match). - Fetch closed-but-unmerged [test-quarantine] PRs + comments with a full token, bypassing the DIFC filter; the closed-PR check now uses this instead of MCP. Recompiled lockfile with gh-aw CLI v0.81.6 (setup action v0.80.9 -> v0.81.6). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
wtgodbe
added a commit
to wtgodbe/aspnetcore
that referenced
this pull request
Jul 6, 2026
…ected actions Two recent misbehaviors (run 28656097334): PR dotnet#67577 tried to unquarantine SetsTlsHandshakeFeatureForHttps despite issue dotnet#49306 carrying the re-quarantine label, and PR dotnet#67576 re-quarantined WebSocketsWorks despite maintainer "do not quarantine" comments on the already-rejected dotnet#67443/dotnet#67415. Root causes: - The unquarantine re-quarantine check only parsed merged-PR diffs and left the match/exclude decision to the model; it never consulted the re-quarantine issue label the maintainer set. - The closed-PR comment check relied on MCP search_pull_requests, whose DIFC filter silently drops the workflow's own app/github-actions-authored PRs, so the maintainer comments were never seen. Fixes (deterministic pre-activation steps + injected data): - Fetch re-quarantine issue numbers; block unquarantine of any test whose tracking issue is labeled re-quarantine (authoritative, exact match). - Fetch closed-but-unmerged [test-quarantine] PRs + comments with a full token, bypassing the DIFC filter; the closed-PR check now uses this instead of MCP. Recompiled lockfile with gh-aw CLI v0.81.6 (setup action v0.80.9 -> v0.81.6). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
wtgodbe
added a commit
that referenced
this pull request
Jul 6, 2026
…ected actions (#67620) Two recent misbehaviors (run 28656097334): PR #67577 tried to unquarantine SetsTlsHandshakeFeatureForHttps despite issue #49306 carrying the re-quarantine label, and PR #67576 re-quarantined WebSocketsWorks despite maintainer "do not quarantine" comments on the already-rejected #67443/#67415. Root causes: - The unquarantine re-quarantine check only parsed merged-PR diffs and left the match/exclude decision to the model; it never consulted the re-quarantine issue label the maintainer set. - The closed-PR comment check relied on MCP search_pull_requests, whose DIFC filter silently drops the workflow's own app/github-actions-authored PRs, so the maintainer comments were never seen. Fixes (deterministic pre-activation steps + injected data): - Fetch re-quarantine issue numbers; block unquarantine of any test whose tracking issue is labeled re-quarantine (authoritative, exact match). - Fetch closed-but-unmerged [test-quarantine] PRs + comments with a full token, bypassing the DIFC filter; the closed-PR check now uses this instead of MCP. Recompiled lockfile with gh-aw CLI v0.81.6 (setup action v0.80.9 -> v0.81.6). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Re-quarantines
Microsoft.AspNetCore.SignalR.Client.Tests.TestServerTests.WebSocketsWorks, which was unquarantined in #67261 but has started failing again on themainbranch.Failures were observed in 3 separate main-branch CI builds after the unquarantine:
All failures occurred in the
batch_3--net11.0Helix work item. The original tracking issue is #65914.Changes
src/SignalR/clients/csharp/Client/test/UnitTests/TestServerTests.cs: Re-added[QuarantinedTest("https://github.com/dotnet/aspnetcore/issues/65914")]attribute toWebSocketsWorks.