Repository navigation
test(Wheel): the busy-thread coast proof decodes each frame once - #10777
Conversation
The coast's busy-main-thread proof tracked three marker colours and the control in four passes over the screencast. Each pass decoded every frame again. Under load the passes took most of the test's 60 s, and the test timed out inside them. One trackMarkers call now decodes each frame once and searches it for every colour, as the harness documents. The tracks are the same, and the timeout is unchanged.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
meta-cla
Bot
added
the
CLA Signed
|
AI review status for this pull request.
|
PR Analysis Report🔎 Preview ·
|
| Component | Size | LoC | Visual · A11y · RTL |
|---|---|---|---|
| DateInput · Storybook | 187.0 kB (0) · 17.0 kB CSS (0) | 5,749 (0) | ✓ · ✓ · ✓ |
Package size: no published package changed; no new dependencies.
API changes: none in this pull request
Committed API report behind this build: cli 29 rows, core 36 rows, theme-butter 1 row, theme-y2k 1 row; run pnpm api:report.
Touched components checked; add ci:run-visual, ci:run-a11y or ci:run-rtl to run the full suites.
Generated by PR Enrichment workflow | View full report
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
Approved pending CI: CI has not run on this head yet.
The single trackMarkers call returns the same four tracks as the three per-colour trackMarker calls and the control's call it replaces: the same tolerance, the whole frame, and the cast step on the magenta track only. The busy-main-thread proof judges exactly what it judged before, with one decode per frame, and format, lint and typechecks pass on the head.
Next step: the pull request is still a draft, so every CI job skipped; it already carries the ci:run label, so marking it ready for review starts CI.
[Automated review]
cixzhang
added
the
ci:run
|
/approve-spec 718b408 |
Maintainer impact
The Wheel's proof "the coast keeps advancing every frame while the main thread is blocked" can run out of time on a loaded runner. On two contended CPUs it took 21–43 s of its 60 s budget, and some runs timed out.
Intended invariant
The proof judges the same frames with the same tracks, against the same control. Its 60 s timeout is unchanged.
Change
The test tracked three marker colours and the control with four
trackMarkercalls. Each call decodes every screencast frame again. Under load, those four passes took about 24 of the test's 30 s.One
trackMarkerscall now decodes each frame once and searches it for all four colours. The harness documentstrackMarkersfor this case: a proof that tracks a marker and a control decodes each frame once.trackMarkeristrackMarkerswith one colour, so each track is the same.Evidence
The recipe: Chromium in the CI image,
--cpus=2on one pinned pair of CPUs, 4 workers, and busy loops inside the container. No other user process ran on the pair. WebKit skips this proof by design, since it needs scripted touch timestamps.trackMarkers,frames.ts:516). A timing probe put each of the four passes at 5.6–7.1 s.FrameStarvationErrorin one run, a verdict failure in the other. That is a known harness issue, outside this change.Scope
Testing
pnpm exec prettier --check, ESLint andpnpm -F @astryxdesign/core typecheckpass.node scripts/release/changeset-coverage.mjs prreports nothing that ships.