chore(mcp): quarantine the MCP-server-tab spec as a recurrent flake (#1335) - #1337
Merged
Merged
Conversation
…1335) `mcp-server-tab.spec.ts:6` flaked on the 2026-08-05 and 2026-08-06 dailies with the same signature — `locator.click: Timeout 3000ms exceeded` waiting for `mcp-server-dropdown`, whose 3 s budget lives in the shared helper `helpers/mcp/open-add-mcp-server-modal.ts:10`. Two same-signature occurrences inside the 30-day window is the recurrent-flake criterion, so the test is quarantined as prevention (CONTRIBUTING.md -> Triage protocol, step 2). Quarantine is both edits together: `@stable` removal alone only stops the daily, leaving the test red on the pr-validation impacted-specs gate, which selects by file diff rather than by tag (#871) — including this PR. `test.fixme` skips it in every context. Lifting the quarantine (remove `test.fixme` + restore `@stable`) is a deliverable of #1335, not of this PR. The QA-CHECKLIST bullets are untouched: the spec still exists and still carries a mirrored doc, so the coverage guard still requires them. Triage: #1330 (run 31093877484).
5 tasks
Contributor
There was a problem hiding this comment.
Pull request overview
This PR quarantines a recurrently flaky MCP server UI test by converting it to test.fixme(...) and removing its @stable tag, preventing it from running in all lanes while investigation proceeds under #1335.
Changes:
- Mark
mcp-server-tab.spec.tstest astest.fixme(...)with an in-file quarantine note referencing #1335. - Remove
@stablefrom the test’s tag list to ensure it no longer counts as validated/stable coverage.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+8
to
+12
| // `helpers/mcp/open-add-mcp-server-modal.ts`. Tracked in #1335; lifting the | ||
| // quarantine (remove `test.fixme` + restore `@stable`) is a deliverable there. | ||
| test.fixme( | ||
| "user should be able to manage MCP server tools and configuration", | ||
| { tag: ["@stable", "@release", "@workspace", "@components", "@mcp"] }, | ||
| { tag: ["@release", "@workspace", "@components", "@mcp"] }, |
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
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.
Quarantines
mcp-server-tab.spec.ts:6("user should be able to manage MCP server tools and configuration") as prevention, perCONTRIBUTING.md→ Triage protocol, step 2.Spun out of daily-failure triage #1330 (run 31093877484, 2026-08-06). The investigation is tracked in #1335 — this PR does not fix anything.
Why
Recurrent flake: same signature on two dailies inside the 30-day window.
TimeoutError: locator.click: Timeout 3000ms exceeded.TimeoutError: locator.click: Timeout 3000ms exceeded.The wait is a 3 s click budget on
mcp-server-dropdownin the shared helpertests/helpers/mcp/open-add-mcp-server-modal.ts:10. (A third hit on 2026-07-27 carries a different signature and does not count toward the criterion.)Why both edits, not just the tag
@stableremoval alone only stops the daily.pr-validation.ymlselects specs by file diff, not by tag (#871) — so the test would still run red on the impacted-specs gate, starting with this very PR.test.fixmeskips it in every context, which is what makes the quarantine hold and this PR merge green.Not touched
QA-CHECKLIST.mdbullets: the spec still exists and still has a mirrored doc, socheck:checklist-coveragestill requires them. Generated blocks are regenerated on merge byupdate-coverage-summary.yml.CONTRIBUTING.md, the traceability record for a quarantine cycle is the triage issue + the dedicated issue + the restoration PR.Lifting the quarantine (remove
test.fixme+ restore@stable, re-validated) is a deliverable of #1335.🤖 Generated with Claude Code