[vjeux]

Maintainer impact

A trace's long tasks reported wall time only. On a busy machine, wall time stretches with the machine, not with the page's work. So a "no long task" check fails on a loaded box when the page's own work is well under the bound.

Intended invariant

A claim about the page's own work judges the main thread's own run time. A claim about a blocking wait (a synchronous request, Atomics.wait) still judges wall time, since a waiting thread gains wall time but no thread time.

Change

• Each traced long task carries threadMs beside durationMs: the main thread's run time from the trace's thread clock, capped at the wall time. A task with no thread clock reads at its wall time, so nothing weakens silently.
• The split into the page's tasks and the harness's own reads moves into a pure longTasksOf, which a unit test reads without a browser.
• The README's paragraph on long tasks says when to judge which.

The harness only. Its first user is the Lab RefreshControl's interaction spec (#9865).

Evidence

• Failure before the change: trace.longTasks.test.ts fails 4 of 4 against main's trace.ts (longTasksOf is not a function).
• Success after the change: its four cases pass: thread time apart from wall time, no thread clock as wall time, a harness read in devtoolsTasks, and no task of 50 ms or less. The harness's node tests pass.
• Product/runtime behavior verified unchanged: no package outside internal/interaction-harness changes; longTasks and devtoolsTasks keep start and durationMs.

Scope

• No intended public API, product behavior, visual direction, or policy change.
• Product changes discovered during the work were removed or split.
• Public text and artifacts contain no internal Meta context.

Testing

Local gates at fe28f88, on main: the harness's node tests (7 files / 129), its type check, strict ESLint and pnpm lint with 0 errors, Prettier, and review:pre with no findings.

[vercel]

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

Project	Deployment	Actions	Updated
astryx	Ready	Preview	Nov 4, 2026 9:40am UTC

[github-actions]

PR Analysis Report

🔎 Preview · 8b90073

Storybook · Sandbox · built from this PR's head

Package size: measured; main has no measurement of the merge base to compare yet.

API changes: none in this pull request

Committed API report behind this build: cli 8 rows, theme-butter 1 row, theme-chocolate 1 row, theme-gothic 1 row, theme-matcha 1 row, theme-neutral 1 row, theme-stone 1 row, theme-y2k 1 row; run pnpm api:report.

Not run on this PR: add ci:run-visual, ci:run-a11y or ci:run-rtl to run them.

---

_{Generated by PR Enrichment workflow | View full report}

[astracat-bot]

AI review status for this pull request.

Review status	Updated
🟢 Reviewed (for maintainers only)	Nov 4, 2026, 9:43 AM UTC

[astracat-bot]

Approved pending CI: CI has not run on this head yet. It starts once the pull request is marked ready for review and a maintainer adds the ci:run label, since the branch lives in a fork.

The new threadMs leaves every existing caller's start and durationMs unchanged, and the longTasksOf test fails without the change and passes with it. One optional addition: no case has a thread duration above the wall duration, so a case such as task(0, 60, 61) expecting threadMs: 60 would pin the cap that TracedTask.threadMs documents.

[Automated review]

[astracat-bot]

Approved pending CI: CI is still running on this head.

The new threadMs leaves every existing caller's start and durationMs unchanged, and the longTasksOf test fails without the change and passes with it. One optional addition: no case has a thread duration above the wall duration, so a case such as task(0, 60, 61) expecting threadMs: 60 would pin the cap that TracedTask.threadMs documents.

[Automated review]