Playwright CI suite runtime up ~63% in 9 days (131s→213s), no sharding — will keep compounding

[mkofler96]

Problem

The "Run frontend tests" step of the Frontend CI job has grown steadily over the last ~9 days, measured directly from workflow run history (ci.yml, job "Frontend", step "Run frontend tests"):

Date	Run	Duration
2026-07-03	#660 (fdeff06)	131s
2026-07-04	#689 (0cfb6f5)	137s
2026-07-09	#715 (ed5bb2f)	160s
2026-07-12	#742 (03e830e, current HEAD)	213s

That's a ~63% increase in under two weeks, with no corresponding change to CI parallelism. web/playwright.config.ts sets no workers/shard option, and the Frontend job in ci.yml runs the whole suite serially in a single runner — there is no --shard matrix like Playwright supports.

Root cause

Six new full end-to-end Playwright spec files were added in the same window (git log --diff-filter=A --since=2026-07-03 -- web/tests):
edge-pick.spec.ts, auto-shell.spec.ts, crane-hook-example.spec.ts, multibody-materials.spec.ts, multibody-solve.spec.ts, new-analysis.spec.ts.

The largest single contributor is the mixed shell/solid case added in #392: web/tests/example-load.spec.ts sets test.setTimeout(180_000) and drives a real in-browser RBE3-coupled CG solve (thousands of iterations per the commit message) against a newly committed 2.06 MB crane-hook-shell.vtu fixture. web/tests/edge-pick.spec.ts (90s timeout, real viewport-click flow) is a secondary contributor.

This isn't a bug in any one PR — it's the natural result of the project's validation strategy (one full-browser-plus-WASM spec per new physics capability) with no CI-side scaling to match. At the current growth rate, the frontend job will keep costing more per PR indefinitely as more example/physics coverage is added (see the roadmap of pending shell/multibody capabilities: #354, #355, #357, #359, #388, #389).

Suggested fix

• Shard the Playwright run across parallel CI jobs (npx playwright test --shard=1/N style matrix), mirroring the pattern CI already uses to run rust / clang-tidy / wasm as separate parallel jobs.
• Alternatively/additionally, split "fast" unit-style specs from "slow" full-solve example specs so the fast set can gate quickly and the slow set runs with more parallelism.
• Track this going forward — e.g. fail CI (or at least warn) if the frontend test step exceeds some threshold, so future growth is caught before it silently becomes the new normal.

Related

Distinct from #365 (no unit tests in the Rust bridge crates — a coverage gap, not a runtime one).

[mkofler96]

Daily codebase audit update — the trend has continued and gotten worse.

"Run frontend tests" step duration, measured directly from run history:

Date	Run	Duration
2026-07-03	#660 (fdeff06)	131s
2026-07-04	#689 (0cfb6f5)	137s
2026-07-09	#715 (ed5bb2f)	160s
2026-07-12	#742 (03e830e)	213s
2026-07-13	#current (17b1297)	236s

+63% → +11% in the one additional commit since this was filed. That commit (#393) didn't add a new spec file itself, but the immediately-preceding work in this window did: web/tests/crane-roundtrip.spec.ts (added alongside #393) sets test.setTimeout(240_000) — a 4-minute budget for a real browser STEP import + full volume mesh + coupled solve — the same shape of expensive full-solve e2e spec already named as the dominant contributor in the original report. Flagging as a likely additional contributor to track down if/when this gets sharded, not a new root cause.

---

Generated by Claude Code

[mkofler96]

Daily codebase audit update — growth rate has slowed noticeably.

Date	Run	Duration
2026-07-12	#742 (03e830e)	213s
2026-07-13 06:01	(17b1297)	236s
2026-07-13 19:00	#current (05f2930, #403)	242s

Only +6s (+2.5%) despite #403 adding two new full e2e specs (ibeam-shell.spec.ts, ibeam-solid.spec.ts) — much smaller than the prior two days' jumps (+23s, +53s). Good sign that not every new physics-capability spec is equally expensive, but the underlying issue (no sharding, single serial runner) is unchanged and the total is still up 85% from the 131s baseline nine days ago. Not closing this out — worth sharding before the next heavy spec (e.g. anything from #397/#354/#355) lands.

---

Generated by Claude Code

[mkofler96]

Daily codebase audit update — the 10-day freeze flagged on 07-24 ended (9 commits landed 07-25→07-29). Continuing the table with the resumption's numbers:

Date	Run	Duration
2026-07-13 19:00	(05f2930, #403)	242s
2026-07-29 18:12	#777 (81663a1)	287s

+45s (+19%) across the resumption window, +119% over the 131s baseline (07-03), still with no sharding. Four new full-browser specs landed in this burst (auto-shell-toggle.spec.ts, auto-shell-toggle-single-body.spec.ts, fin-midsurface.spec.ts, legend-range.spec.ts), consistent with the jump. Same recommendation as every prior update on this issue: shard before the next heavy spec lands, since the "no sharding, single serial runner" root cause hasn't moved despite 6 status updates now.

---

Generated by Claude Code

[mkofler96]

Regression update — still worsening, no sharding added yet

Checked the "Run frontend tests" step duration on main CI runs since this issue was filed:

Date	Run	"Run frontend tests" step duration
(baseline in this issue) ~end of June	—	131s
2026-07-09 (issue filed)	—	213s (+63%)
2026-08-07 (run #791, latest main)	31147398368	352s (+65% more, +169% vs. original baseline)

Whole-workflow wall clock on main has also been trending up over the same window (394s → 629s → 475s → 447s → 626s → 456s → 467s → 566s → 524s → 698s → 687s across the last 11 completed main runs), consistent with the Playwright suite continuing to grow without sharding.

No action appears to have been taken on this issue yet (no sharding, no --shard config in .github/workflows/ci.yml, test count keeps growing with each new feature area — ties, couplings, MPC validation, shell coupling — each adding its own spec file). Re-flagging since the growth trend hasn't slowed and is now over 2.5x the original baseline.

---

Generated by Claude Code

[mkofler96]

Update from today's codebase audit — this has kept compounding, un-sharded, since the issue was filed:

Date	Run (HEAD)	"Run frontend tests" duration
2026-07-12	#742 (03e830e)	213s
2026-07-29	30478680632 (81663a1)	287s
2026-08-13	31668981408 (e7855e9, current main)	472s

That's +121% over five weeks, and +64% in just the last two. The suite has continued growing with each new shell/multibody/coupling feature (per this run's git log, at least edge-pick, multibody-*, auto-shell, and the surface-to-point coupling work all landed full E2E specs in that window), exactly the pattern this issue predicted. No sharding has been added to .github/workflows/ci.yml's Frontend job yet.

Flagging so this doesn't keep sliding — at the current rate the Frontend job will pass 10 minutes within a few more weeks of physics-feature PRs.

---

Generated by Claude Code

[mkofler96]

Daily codebase audit update — still compounding, still unsharded.

Date	Run (HEAD)	"Run frontend tests" duration
2026-08-13	31668981408 (e7855e9)	472s
2026-08-19/20	32274522075 (9b055f7, current main)	526s

+11% since the last check, +302% over the original 131s baseline six weeks ago. Whole-job wall clock (including setup/build/smoke-test) is now ~11 minutes. Still no --shard in .github/workflows/ci.yml's Frontend job, and three more full-browser-plus-WASM specs' worth of shell/coupling work (#429, #430, #431) landed in this window. Same recommendation as the last 7 status updates: shard the Playwright run, or split fast unit-style specs from slow full-solve example specs.

---

Generated by Claude Code