e2e: 6 tests fail only on GitHub Actions despite passing locally

[KrasimirKralev]

Summary

Six e2e specs reliably fail on GitHub Actions runners but pass cleanly on the Jetson worktree (verified 7-18s per test in isolation, even with 3 parallel workers). Bumping per-test timeout to 60s and action/expect timeouts to 15s did not fix the issue.

Affected specs

• e2e/browser-vnc.spec.ts — "browser app installs chromium..."
• e2e/desktop-selection.spec.ts — "desktop background context menu can launch the terminal"
• e2e/installed-app-settings.spec.ts — "installed app settings can save configuration..."
• e2e/mascot-context.spec.ts — "mascot tap opens the chat popup"
• e2e/terminal-reconnect.spec.ts — "terminal can open and connect to the websocket backend"
• e2e/clawkeep-interactions.spec.ts — "unpair flow opens the confirm dialog..."

All six are currently test.fixme(...) with a comment pointing back to PR #113.

Failure shape

Each fails at the first user action with a timeout — getByRole('button', { name: ... }).click() or similar — even though the parent locator (getByTestId('app-launcher'), chrome-window-clawkeep, etc.) resolved fine. The tests can see the desktop / window mounted, just can't interact with what's inside.

Investigation done

• .scratch/investigate-failing-tests.sh runs the 5 originally-flaky specs in a fresh git worktree on the Jetson with bunx playwright test --grep-invert fixme. All 5 pass in ~17.8s with 3 parallel workers.
• Bumping actionTimeout 5s → 15s, navigationTimeout to 30s, timeout (per-test) 30s → 60s, and expect.timeout to 15s did not change the failure pattern on GH Actions.
• Total e2e job runtime stays 5-7 minutes on GH Actions vs ~1.6 minutes when the failing tests are skipped.

Likely causes

• Runner memory/CPU pressure with bun run dev under sequential workers:1
• Different chromium build / display server setup on GH runner vs Jetson
• Possible font-rendering or accessibility-tree differences affecting getByRole matching

Suggested next steps

• Reproduce on a self-hosted GH runner with the same image as Jetson, isolate which environmental variable matters.
• Try sharding (workers: 2) or splitting e2e into multiple jobs to spread the dev-server load.
• Consider switching e2e to a production build (bun run start) instead of bun run dev so Turbopack doesn't recompile on demand under each test.

[KrasimirKralev]

Attempted fix in #156 (now reverted): switching the e2e webServer from bun run dev to a production build (next build + production-server.js) to remove Turbopack recompile-under-load.

Result: it broke 33/41 specs on CI. The build + server started fine, but the suite is written against the dev server — the standalone production server differs enough (middleware/proxy, origin/host enforcement, instrumentation/terminal-server bring-up) that nearly every page-loading test failed. Only pure-API/mock specs passed.

Conclusion: the production-build approach isn't viable without reworking how the suite bootstraps. Alternatives to try next: (a) keep bun run dev but shard with workers: 2 to cut per-server load, or (b) make the production-server path test-aware (stub the gateway/terminal deps, relax origin checks under a test flag). The 6 specs stay test.fixme()'d until then. Low priority — developer-only, no customer impact.

[KrasimirKralev]

Reopening: this auto-closed when v3.0.7 merged to main (commit 38c325e carried a closing keyword for #114). That commit was the production-build e2e webServer attempt, which we reverted in 6804ad8 — but a revert doesn't remove the original commit from history, so its keyword still fired on the merge to the default branch.

The underlying issue is not resolved: the 6 e2e specs (browser-vnc, desktop-selection, installed-app-settings, mascot-context, terminal-reconnect, clawkeep-interactions) are still test.fixme()'d and only fail on GitHub Actions. Next step remains evidence-first: pull the Playwright trace/console from a failing CI run before attempting another fix (the prior timeout-bump and prod-build approaches were guesses).