fix(html): raise testTimeout to 15s for parallel-load reliability#1448
Merged
cjpillsbury merged 1 commit intomainfrom Apr 23, 2026
Merged
fix(html): raise testTimeout to 15s for parallel-load reliability#1448cjpillsbury merged 1 commit intomainfrom
cjpillsbury merged 1 commit intomainfrom
Conversation
Under `pnpm test` at the workspace root, turbo runs every package's vitest in parallel (plus spf/dom which spawns Chromium via Playwright), which can push dynamic `await import()` calls in the define/* tests past the 5s default. Locally reproduced: src/define/tests/ssr-safety and registration timed out at 5006ms on a 10-core machine; the same suites pass in 1–2s when run in isolation or with turbo concurrency capped. Bumping the per-file timeout to 15s gives ~3x headroom over the worst observed import under load without hiding real regressions — anything approaching the new ceiling would still fail. The knob is scoped to the html package so it doesn't touch other packages' configs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
✅ Deploy Preview for vjs10-site ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
📦 Bundle Size Report🎨 @videojs/html — no changesPresets (7)
Media (8)
Players (3)
Skins (29)
UI Components (25)
Sizes are marginal over the root entry point. ⚛️ @videojs/react — no changesPresets (7)
Media (7)
Skins (26)
UI Components (20)
Sizes are marginal over the root entry point. 🧩 @videojs/core — no changesEntries (9)
🏷️ @videojs/element — no changesEntries (2)
📦 @videojs/store — no changesEntries (3)
🔧 @videojs/utils — no changesEntries (10)
📦 @videojs/spf — no changesEntries (3)
ℹ️ How to interpretAll sizes are standalone totals (minified + brotli).
Run |
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.
Summary
testTimeoutinpackages/html/vitest.config.tsfrom Vitest's 5s default to 15s so define/* tests that dynamicallyawait import()composite modules stay reliable whenpnpm testruns at the workspace root.Background
Under
pnpm testat the workspace root, turbo (concurrency: 20) runs every package's vitest in parallel, and@videojs/spfadditionally spawns Chromium via Playwright for itsdomproject. On a 10-core machine this is enough CPU contention that a singleawait import('../video/player')orawait import('../video/skin')can exceed 5s through Vite's transform pipeline and time out — observed 5006ms, just past the default ceiling.Same suites run in 1–2s in isolation (
pnpm -F @videojs/html test) and underpnpm turbo run test --concurrency=1, which confirms the issue is scheduler starvation rather than a test bug. Thessr-safetytest amplifies this because it callsvi.resetModules()inafterEach, so each case re-transforms the full graph with no cache benefit.CI runs per-package in isolated jobs, so CI has never observed this. The problem is purely local to anyone whose machine can't absorb the parallel load within 5s.
Why 15s
Observed worst case is ~5s; 15s gives ~3x headroom under load. This doesn't mask regressions — a truly slow import would still fail, just at a higher threshold. The timeout is only consulted when a test exceeds it, so fast environments (CI, beefy laptops) pay nothing.
Alternatives considered
pnpm buildandpnpm devat root for everyone; too broad for a local-only problem.Test plan
pnpm -F @videojs/html test— 14 files, 101 tests, all pass (no change in isolated behavior)pnpm turbo run test --force --filter='./packages/*' --filter='!@videojs/cli'reproduced under load — all 14 packages green, html runs at 11–19s wall duration with 30–50s cumulative transform time (confirms the contention is real; timeout bump absorbs it)🤖 Generated with Claude Code
Note
Low Risk
Low risk: only adjusts Vitest configuration for the
htmlpackage, with no production code or runtime behavior changes. Main impact is potentially slower feedback if a test hangs, since failures may take longer to time out.Overview
Increases the
@videojs/htmlVitesttestTimeoutto 15s to prevent timeouts indefine/*tests that perform heavy dynamicimport()work when the workspace runs tests in parallel.Adds inline documentation explaining the rationale (CPU contention during root
pnpm test) and keeps the change scoped topackages/html.Reviewed by Cursor Bugbot for commit 3a3c50d. Bugbot is set up for automated code reviews on this repo. Configure here.