fix(e2e): warm Turbopack before the suite (partially addresses #114) - #318
Conversation
The e2e job serves the app with `bun run dev` (workers:1), so the FIRST hit to
a route pays its full on-demand Turbopack compile. Under GitHub Actions load
the cold compile of `/` (the desktop shell) can outlast the 15s expect timeout,
which is why six specs failed only on CI while passing on the Jetson β and why
chat-popup started timing out on `getByTestId('desktop-root')` after the
next 16.2 bump nudged that compile past the threshold.
Add a Playwright global-setup that loads `/` and `/setup` once before any test
clock starts, paying the compile up front. Re-enable the six specs that were
`test.fixme`'d for this exact GH-Actions-only flake:
- browser-vnc, desktop-selection, installed-app-settings,
mascot-context, terminal-reconnect, clawkeep-interactions
Left as-is: clawkeep-flow's two fixmes (a separate ClawKeep-redesign gap, not
this flake).
Closes #114.
|
Warning Review limit reached
Next review available in: 12 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review detailsβοΈ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: π Files selected for processing (8)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
π¦ ClawReviewYour friendly reef crab, here with the lay of the land. Adds a new Playwright At a glance
Good to know
β ClawReview π¦, your resident reef crab. Just orientation β CodeRabbit does the line-by-line, humans do the merge. Conventions: docs. |
The CI run showed the global-setup warmup reliably fixes the cold-compile class (chat-popup's desktop-root render, and terminal-reconnect's WebSocket race) but NOT the five DOM-interaction specs β those still time out at their first click / context-menu on GitHub Actions, a deeper post-mount/hydration lag under `bun run dev` workers:1 that a route warmup doesn't touch. Re-fixme the five interaction-lag specs (browser-vnc, desktop-selection, installed-app-settings, mascot-context, clawkeep-interactions) with an accurate note; keep terminal-reconnect enabled (verified green). The residual stays tracked in #114.
Partially addresses #114 (does not close it β see below).
Root cause
The e2e job serves the app with
bun run dev(workers: 1), so the first request to a route pays its full on-demand Turbopack compile. Under GitHub Actions load the cold compile of/(the desktop shell) can outlast the 15s expect timeout. That's whychat-popupstarted failing the moment thenext16.2 bump (#315) nudged that compile past the threshold, and it's one half of #114.Fix
A Playwright
globalSetuploads/and/setuponce, before any test clock starts, so the one-time compile happens up front.What the CI run proved
The warmup reliably fixes the cold-compile class:
chat-popup(desktop-root render) β this unblocks the fix(deps): patch runtime security advisories (next, undici, ws, postcss, nanoid, sharp)Β #315 security PRterminal-reconnect(WebSocket handshake no longer races the compile) β re-enabled hereIt does not fix the interaction-lag class β five specs still time out at their first DOM click / context-menu on GH Actions (a deeper post-mount/hydration lag under
workers: 1):browser-vnc,desktop-selection,installed-app-settings,mascot-context,clawkeep-interactions. Those stayfixme'd with an accurate note and remain tracked in #114.Net
Compile-latency root cause fixed + 1 of the 6 flaky specs restored + chat-popup made robust. The remaining 5 need the deeper CI-infra work (production build for e2e, or sharding/
workers: 2) β the production-build path is entangled with the dev-bundle coverage report, so it's its own task. Leaving #114 open for that.