modelcontextprotocol/inspector
Watch
1
0
Fork
You've already forked inspector
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

docs: record why maxWorkers stays unset, with the measurement (#2336)

Browse source 
No Vitest project sets `maxWorkers`, so every one inherits Vitest's
`availableParallelism() - 1` (7 on the team's M3). #2336 asked whether that
number should be stated or capped. Measured at the leased baseline (#2339),
interleaved default / --maxWorkers=4 / default, three rounds each: a cap of 4
costs +14% wall on the web unit suite and +39% on coverage:web, saves 18-22%
CPU, and prevents zero failures (0 of 18 runs either way). Against a sibling
session's concurrent unit run it is a small politeness trade with no
throughput gain; the only failures seen were one test's 5s inner waitFor at
14 workers, which is a site to fix rather than a reason to cap.

So the default is kept, as a chosen value: the reasoning and the numbers sit
beside TIMEOUTS in vitest.shared.mts, and AGENTS.md carries the rule so a
reviewer can cite it against a future per-project cap. CI is unaffected.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PsmUAZ6aLUAFqenjJKSSRp
Signed-off-by: cliffhall <cliff@futurescale.com>
This commit is contained in:
cliffhall 2026-09-13 00:13:39 -04:00
commit f128ec62d0
1 changed files with 58 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

9
AGENTS.md
View file

@ -457,6 +457,15 @@ free to run a full `local:gate`). Raising a budget nobody chose hides no race.
project, reading the value Vitest resolved for the test — so a per-test
option, a `describe` option, a project setting and a `--retry` flag all land
on the same check.
- **`maxWorkers` stays unset — on measurement, not by omission (#2336).** Every
Vitest project inherits `availableParallelism() - 1`. Capping it to 4 was
measured at the leased baseline as +14% wall on the web unit suite and +39%
on `coverage:web` for zero fewer failures (0 of 18 runs either way), so the
cap is a permanent solo-run cost. The only thing it moved was one test's 5s
inner `waitFor` when two sessions ran suites at once — a site to fix, not a
reason to cap. The numbers, the sibling-session trade and what would reopen
the question are on the comment in `vitest.shared.mts`; do not add a
per-project cap without re-running that measurement.
- **The Playwright locator budgets the web smokes use are named constants in
`scripts/lib/browser-timeouts.mjs`** — raise one there, not at a call site.
The *remaining* smoke-helper budgets and CI's missing `timeout-minutes` are