The inline finding was a real bug: main() never called the discovery check, so the deny-by-default claim rested on test:scripts happening to run the same comparison — a different command, which `npm run verify:test-timeouts` does not invoke. `failures` is now seeded from it, and a probe config under clients/ was observed to fail the guard. Three suppressed findings, all correct. The afterEach in oauth-interactive restated the shared hookTimeout and labelled it as a round trip, when it only stops a server and unlinks a file; it now carries no budget. The file-lock constants were named for the opposite of what they bound — 90s covers retries running out against a holder that never yields, 60s covers the stale-lock takeover that succeeds — so they are LOCK_RETRIES_EXHAUSTED_MS and STALE_LOCK_TAKEOVER_MS. The browser-timeouts header said 15 budgets; it is 19. Separately, and more importantly: the asyncUtilTimeout raise is reverted, on measurement. Verifying round 2 turned up intermittent 15s timeouts across unrelated unit files, so three arms of three full unit runs were taken in this worktree at comparable load — unmodified v2/main 3/3 green, this change with 5000 producing 1, 4 and 0 timing-out files, and the same change with that one line reverted 3/3 green. A wait that is MEANT to expire spends its whole budget on the happy path, so a 5x raise is a 5x cost on exactly those tests and saturates the worker pool, starving tests that were never slow. Both web setup files therefore state asyncUtilTimeout at the library's own value rather than raising it, which is what #2323's rule actually asks for: a budget nobody chose is the defect, not a budget that is small. The tests that assert absence by letting a wait expire are the real problem and are #2335. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PsmUAZ6aLUAFqenjJKSSRp Signed-off-by: cliffhall <cliff@futurescale.com>
35 lines
1.8 KiB
TypeScript
35 lines
1.8 KiB
TypeScript
/**
|
|
* Setup file for the `storybook` Vitest project (#2323).
|
|
*
|
|
* It exists for one call. Storybook's instrumented Testing Library carries its
|
|
* own `asyncUtilTimeout`, and it governs the 80 `waitFor` / `findBy*` sites
|
|
* across the story files. It is the *tighter* of the two bounds this project
|
|
* has — the per-test ceiling is 15000 (#2292) — so it is stated here rather
|
|
* than inherited, which also pins it against a Storybook upgrade changing the
|
|
* default under all 80 sites at once.
|
|
*
|
|
* The value matches the unit project's, and for the reason recorded in
|
|
* `setup.ts`: raising it was measured and rejected. A wait that is *meant* to
|
|
* expire spends its whole budget on the happy path, so a raise is a
|
|
* proportional cost on exactly those tests.
|
|
*
|
|
* ⚠️ Two things about this file that are deliberate and easy to undo:
|
|
*
|
|
* 1. **It must not live in `.storybook/`, and must not call
|
|
* `setProjectAnnotations`.** `@storybook/addon-vitest` provisions the
|
|
* preview annotations itself, and skips doing so when it finds a setup file
|
|
* that is *both* inside `configDir` and contains that call (#1898) — so the
|
|
* old `.storybook/vitest.setup.ts` was opting out of the automatic path.
|
|
* Either half of the condition is enough to stay on it; this file misses
|
|
* both. `src/test/PreviewAnnotations.stories.tsx` asserts the provisioning
|
|
* directly, so a regression here fails a test rather than silently rendering
|
|
* every story without the Mantine decorator.
|
|
* 2. **The import is `storybook/test`, not `@testing-library/*`.** Storybook
|
|
* instruments its own copy so the interactions panel can trace each step;
|
|
* configuring a different copy would change nothing that a play function
|
|
* actually calls.
|
|
*/
|
|
|
|
import { configure } from "storybook/test";
|
|
|
|
configure({ asyncUtilTimeout: 1000 });
|