test(hub-client): raise WASM testTimeout to 120s — hang detection, not a perf budget - #440
Merged
Conversation
…t a perf budget The smoke-all sweep (one it() over every fixture) ran at ~85-90% of the 30s testTimeout on ubuntu CI runners; #438 added ~1s of SCSS work and runner variance tipped it over, failing main at 727b050. Timeouts should sit at 5-10x typical duration and only catch genuine hangs. Per-fixture refactor deferred to bd-0yyy4ipi. Full diagnosis and the heuristics behind the number: claude-notes/research/2026-07-30-test-timeouts-are-hang-detection.md Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Raises
testTimeoutinhub-client/vitest.wasm.config.tsfrom 30s to 120s, and adds a research note documenting the diagnosis and the heuristics behind the number.Why
The TS Test Suite failed on
mainat 727b050: the smoke-all WASM sweep (smokeAll.wasm.test.ts, which renders every fixture inside a singleit()) timed out at 30.5s on the ubuntu leg. It was not a code regression — the sweep was already running at ~85–90% of the 30s budget on ubuntu runners (25.5s pre-#438, 26.5s on #438's own green pre-merge CI); #438 added ~1s of SCSS work and normal runner variance tipped it over. The macOS leg of the same run passed in 20.1s.A test timeout's job is hang detection, not performance enforcement, so it should sit at 5–10× typical duration (cf. Go's 10-minute default, Bazel's coarse size buckets, nextest's warn-vs-kill split). The new value is marked as such in a comment so it doesn't get re-tightened in a cleanup pass.
Full incident table + heuristics:
claude-notes/research/2026-07-30-test-timeouts-are-hang-detection.md.Follow-up (deliberately deferred, rule-of-three): bd-0yyy4ipi — split the monolithic sweep into per-fixture tests via top-level
await+it.each.Verification
npm run test:wasmlocally after a freshnpm run build:wasm: 21 files / 130 tests pass, smoke-all sweep included.🤖 Generated with Claude Code