Summary
The catalog-refresh Plan-mode Desktop e2e scenarios can observe the fake backend response and then race with the live-turn control state. The Plan menu row becomes disabled while the test is trying to click it, causing a deterministic 30-second Playwright timeout in otherwise unrelated pull requests.
Evidence
This reproduced twice on #3789, whose diff against main contains no files under apps/desktop or packages/ui:
ef6171984 run: latest Plan intent still reaches the Host after a catalog refresh fails timed out on the second planRow.click(); the row had aria-disabled="true" with the running-task description.
b11da18e7 run: after rebasing onto current main, a failed catalog refresh keeps the committed Plan state visible timed out on its first planRow.click() because Playwright observed the row as not enabled.
Both runs passed planner, inventory, lint, format, build, release contracts, typecheck, workspace tests, Eval proxy, Runtime Host tests, and the separate windows_recovery job before Desktop e2e failed. The failures moved between adjacent scenarios, which points to a shared turn-settlement/test-barrier race rather than scenario-specific product behavior.
Expected
After the fake backend turn has actually settled, the Plan row should remain enabled long enough for these tests to exercise the intended pending/failed sessions.list catalog-refresh behavior.
Suggested closure
- Establish a deterministic turn-completion barrier before arming the catalog-refresh latch and clicking Plan.
- Preserve the test's real purpose: pending and failed catalog refreshes must not lose the latest Plan intent or committed state.
- Run the focused catalog-refresh Plan scenarios repeatedly to prove the timing race is closed.
- Run the full Desktop e2e suite.
Found while validating #3789; this issue is independent of that PR's Windows storage/ADS changes.
Summary
The catalog-refresh Plan-mode Desktop e2e scenarios can observe the fake backend response and then race with the live-turn control state. The Plan menu row becomes disabled while the test is trying to click it, causing a deterministic 30-second Playwright timeout in otherwise unrelated pull requests.
Evidence
This reproduced twice on #3789, whose diff against
maincontains no files underapps/desktoporpackages/ui:ef6171984run:latest Plan intent still reaches the Host after a catalog refresh failstimed out on the secondplanRow.click(); the row hadaria-disabled="true"with the running-task description.b11da18e7run: after rebasing onto currentmain,a failed catalog refresh keeps the committed Plan state visibletimed out on its firstplanRow.click()because Playwright observed the row as not enabled.Both runs passed planner, inventory, lint, format, build, release contracts, typecheck, workspace tests, Eval proxy, Runtime Host tests, and the separate
windows_recoveryjob before Desktop e2e failed. The failures moved between adjacent scenarios, which points to a shared turn-settlement/test-barrier race rather than scenario-specific product behavior.Expected
After the fake backend turn has actually settled, the Plan row should remain enabled long enough for these tests to exercise the intended pending/failed
sessions.listcatalog-refresh behavior.Suggested closure
Found while validating #3789; this issue is independent of that PR's Windows storage/ADS changes.