You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Two pre-existing @smoke failures have made frontend-e2e red on dev since 2026-06-10 (first seen on the #1114 run; reproduced identically on #1133). Because the workflow is ui-label-gated, several PRs merged while the suite was silently red.
1. smoke.spec.js — operating room page loads
The test navigates /operating-room and asserts getByText(/operating|queue|priority|all types|no items/i). Since #1109 the route redirects to /operations, whose visible text (heading Operations, tabs Needs Response / Notifications / Health / Executions / Resolved, empty state "All clear — your agents are working independently") matches none of those patterns. The redirect itself works — pure assertion drift.
McpKeysTab.vueonMounted awaits fetchApiKeys() then fires POST /api/mcp/keys/ensure-default; when no user-scoped key exists it auto-creates Default MCP Key and opens the "Your MCP API Key is Ready!" modal. In CI the test deletes its own key per-test, so test 2's page load re-creates the default key and the auto-modal lands on top of the test's Create modal (both fixed z-10 inset-0; later DOM node wins) — the Create click is intercepted for 30s (screenshot in the run artifacts shows the auto-modal covering the form). Timing was marginal; the #1107/#1109 UI changes tipped it into failing consistently. Note test 1's clipboard assertions can pass against the auto modal (same buttons, format-only assertions), so it green-washes the race.
api-keys spec: beforeEach calls ensure-default via page.request (token from localStorage) and reloads — the page's own ensure-default is then a guaranteed no-op and the auto-modal cannot appear mid-test.
Found while validating #1133 (vue-router 5 + vite 8): identical failures on vanilla dev (#1114 run) rule out the router bump as the cause.
Two pre-existing
@smokefailures have madefrontend-e2ered on dev since 2026-06-10 (first seen on the #1114 run; reproduced identically on #1133). Because the workflow isui-label-gated, several PRs merged while the suite was silently red.1.
smoke.spec.js— operating room page loadsThe test navigates
/operating-roomand assertsgetByText(/operating|queue|priority|all types|no items/i). Since #1109 the route redirects to/operations, whose visible text (heading Operations, tabs Needs Response / Notifications / Health / Executions / Resolved, empty state "All clear — your agents are working independently") matches none of those patterns. The redirect itself works — pure assertion drift.2.
api-keys-copy.spec.js— Copy key icon button (race)McpKeysTab.vueonMountedawaitsfetchApiKeys()then firesPOST /api/mcp/keys/ensure-default; when no user-scoped key exists it auto-creates Default MCP Key and opens the "Your MCP API Key is Ready!" modal. In CI the test deletes its own key per-test, so test 2's page load re-creates the default key and the auto-modal lands on top of the test's Create modal (bothfixed z-10 inset-0; later DOM node wins) — the Create click is intercepted for 30s (screenshot in the run artifacts shows the auto-modal covering the form). Timing was marginal; the #1107/#1109 UI changes tipped it into failing consistently. Note test 1's clipboard assertions can pass against the auto modal (same buttons, format-only assertions), so it green-washes the race.Fix (test-only)
/operations+ heading + a tab button (doubles as coverage for the legacy redirect).beforeEachcallsensure-defaultviapage.request(token from localStorage) and reloads — the page's ownensure-defaultis then a guaranteed no-op and the auto-modal cannot appear mid-test.Found while validating #1133 (vue-router 5 + vite 8): identical failures on vanilla dev (#1114 run) rule out the router bump as the cause.