[david-crespo]

I looked into speeding up local e2e runs and fixing some flakes we keep seeing in CI. Not sure whether the speedup is worth it here, but it is pretty big for the occasional local full suite run.

Speedup

A Playwright trace is a recording of a test run that you open in the trace viewer: a DOM snapshot before and after each action, plus screenshots, network requests and console output. Locally we ran with trace: 'retain-on-failure', which records a trace for every test and throws it away when the test passes. Local runs now default to off; pass --trace retain-on-failure when chasing a flake (noted in AGENTS.md and the debug-e2e skill). CI keeps on-first-retry, which only records on retries.

Wall-clock time on my 14-core Mac, Chrome only, 9 workers (the local default), with tracing on and off runs interleaved. Times include starting the dev server.

Run	Runs each	Tracing on	Tracing off	Saved
One test (can resize a failed or stopped instance)	5	12.0–14.2 s (median 12.1)	11.3–12.1 s (median 11.5)	~5%
instance.e2e.ts (19 tests)	3	21.8–22.9 s (median 22.7)	19.4–20.2 s (median 20.2)*	~11%
Full suite (429 tests)	2	236.5–245.3 s	182.7–183.0 s	~24%

* The range leaves out a third tracing-off run that took 44.6 s. The median includes it.

I also considered running e2e against the production build. Every test starts in a fresh browser context, so every page load refetches every unbundled module from the Vite dev server. The production build is faster for the full suite: on the Mac, main took 210 s and the production build with tracing off took 154–156 s (two runs each, 402 tests). But the build runs before every invocation, so a single test got slower, 7.9 s against 6.2 s on the dev server, and the break-even is probably somewhere around 20–30 tests. Locally we mostly run one file or one test, and CI runs the full suite. Supporting both dev and prod servers also meant some noisy fixes for 13 tests that assumed the dev server, across 10 files, and e2e would no longer run with StrictMode double effects or React dev warnings. It could still make sense for CI later.

Flakes

• support-bundles › bundle deleted mid-view 404s failed on Firefox in 3 of the last 11 CI runs, once on all three attempts on main. It has 3 s to see the bundle in destroying, and the toast helpers slept 1 s after every dismissal (added in Sleep after closing toast in E2E to reduce flake #1832, nobody knew why). They now wait for the toast to leave the DOM. On Firefox it went from 5/10 passing to 10/10, and 10 toast-heavy specs showed no new failures.
• vpcs › can nav to VpcPage from / failed its first attempt on Chrome in 7 of the last 11 CI runs. The VPCs link locator also matched the project-no-vpcs link in the projects table, still on screen on a slow runner. With exact: true and Chrome's CPU throttled 2x, it went from 0/20 passing to 20/20.
• route-announcer › route announcer failed on Firefox in 7 of the last 11 CI runs. react-aria removes each announcement after 7 s, before a slow runner gets to the assertion. The test now records announcements as they appear. With a 7.5 s pause added after a nav, the old test failed 5/5 on Firefox and the new one passed 5/5.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
console	Ready	Preview	Nov 12, 2026 7:18pm UTC

[david-crespo]

This is kinda gnarly? Not sure it's worth it, I would almost rather delete the test than do something like this.

[fakemonster]

mostly doesn't bother me, although observing the whole document feels silly. you could dispose of the first observer and make a new one once you've found a mutation where the target is the announcer element, but depending on your definition of "gnarly" that's worse than an overactive mutation observer in a test suite!

[david-crespo]

And it still flaked in firefox. Come on.