FE-1589: Skip the flaky browser-plugin inference Playwright tests - #9536
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 4 Skipped Deployments
|
PR SummaryLow Risk Overview Those scenarios still exercise popup tabs, entity-type selection, debounced Reviewed by Cursor Bugbot for commit bbefb78. Bugbot is set up for automated code reviews on this repo. Configure here. |
There was a problem hiding this comment.
🟢 Approval recommended
The focused change correctly implements the documented temporary quarantine.
Pull request overview
Temporarily quarantines a flaky browser-plugin Playwright test to prevent unrelated merge-queue failures.
Changes:
- Marks the one-off inference persistence test as skipped.
- Leaves the remaining extension tests enabled.
File summaries
| File | Description |
|---|---|
tests/hash-playwright/tests/extension/browser-plugin.spec.ts |
Skips the flaky one-off inference test. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
The sibling automatic-inference test shares openPopupTab and waitForPopupStateLoaded with the already-quarantined one-off test and failed the same way: page.evaluate at browser-plugin.spec.ts:32 threw "Target page, context or browser has been closed" after the 30s test timeout.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit bbefb78. Configure here.

Requested by Ciaran Morinan · Slack thread
🌟 What is the purpose of this PR?
Before: the extension test
user can configure a one-off inference, and the settings are persistedfailed often on CI. It accounted for most of theTestworkflow's failures over 3 and 4 September. The suite runs with no retries by design, so one flake fails the whole run and ejects unrelated PRs from the merge queue. The failures point at the tests' own waits rather than at the extension, so there is no sign the plugin is broken for users.After: that test and its sibling
user can enable automatic inference, and the settings are persistedare skipped, so they can no longer block unrelated work. The other four tests in the file still run, including the logged-out and logged-in popup checks and the options page checks, so the extension keeps its coverage everywhere else. The one-off and automatic inference paths are uncovered until the tests are fixed.This is a temporary quarantine, not a fix. FE-1589 tracks restoring both.
🔗 Related links
🚫 Blocked by
🔍 What does this change?
Two tokens:
test(becomestest.skip(on the two tests with observed failures.No comment is added at either skip. House style keeps comments timeless and free of ticket references, and the file's existing
test.skipcarries none either. The tracking lives in FE-1589.Which tests are skipped
Two:
browser-plugin.spec.ts:256—user can configure a one-off inference, and the settings are persistedbrowser-plugin.spec.ts:291—user can enable automatic inference, and the settings are persistedThe first was the only one with observed failures when this PR was opened. I checked five runs individually and all five reported it:
:281:160:160:32:32:281The varying line numbers do not implicate other tests. Lines 32, 70 and 160 sit in helpers (
waitForPopupStateLoaded,openPopupTab,signOutAndReloadPopup) that this test calls, so they appear in its own stack.The sibling automatic-inference test was left running on that evidence. It then failed on this branch, in the run that quarantining the first test made possible:
That is the same helper and the same end state as the one-off test's failures. It shares
openPopupTabandwaitForPopupStateLoaded, so the quarantine covers it too.Diagnosis
The cause is not established. Two findings about the spec's waits are the place to start, and both are hypotheses:
waitForPopupStateLoadedtreats "chrome.storage.localidle for 500 ms" as the signal that the popup has loaded. The popup polls flow runs every 2 seconds and writes each result to storage, so an idle window says nothing about readiness. When writes bunch up the wait never resolves and spends the whole 30 s budget, which matches theTarget page, context or browser has been closedend state in both tests. When they do not, it resolves before the popup's user fetch has landed.getUseroverwrites the locally stored inference settings with the database copy every time it runs, and the popup renders as soon as a user is present in storage, which can precede its owngetUserreturning. AgetUserlanding after the test has picked its entity types would revert the settings, and the debounced save would then persist the reverted value. That would keep the type picked first and drop the one picked second — the shape of theActorpresent /Documentmissing failure.Both tests reaching the timeout inside
waitForPopupStateLoadedpoints at the first hypothesis over the second.Also worth changing when the tests are fixed: the chips are matched by a MUI class plus a text regex (
.MuiChip-labelfiltered on/^Document$/), which is fragile and gives a poor failure message. There is nodata-testidon them today; adding one would be better than the class-plus-regex match.Pre-Merge Checklist 🚀
🚢 Has this modified a publishable library?
This PR:
📜 Does this require a change to the docs?
The changes in this PR:
🕸️ Does this require a change to the Turbo Graph?
The changes in this PR:
The one-off and automatic inference flows have no automated coverage while the skips are in place. That is the cost of the quarantine and the reason FE-1589 exists.
🐾 Next steps
FE-1589: establish the cause, replace the storage-idle waits with waits on the specific requests that populate the popup, and remove both skips. Fixed sleeps, Playwright
retriesand a longer test timeout are all ruled out.🛡 What tests cover this?
None — this removes two tests from the run. The remaining four tests in
browser-plugin.spec.tsare unchanged.❓ How to test this?
yarn workspace @tests/hash-playwright test:integration.browser-plugin.spec.tspasses.🤖 Generated with Claude Code
https://claude.ai/code/session_01LreriWwCC66TPmMjQVNATJ