[Bug]: "Run component tests" panel stuck on "Starting..." with UniversalStoreFollowerTimeoutError on Windows (10.5.7)

[michele-ines]

Describe the bug

The "Run component tests" panel in the Storybook UI gets stuck on "Starting..." and never runs tests.

The console shows:

• SB_MANAGER_UNIVERSAL-STORE_0001 (UniversalStoreFollowerTimeoutError)
• Timed out waiting for leader state for UniversalStore follower with id: 'storybook/test-provider'
• Error: Failed to start test runner process

This happens on a fresh npm install with Storybook 10.5.7. Downgrading to 10.4.6 fixes the issue completely.

Related: #33575

Reproduction link

https://github.com/zhanganderson/react-vite-storybook-vitest.git

Reproduction steps

The "Run component tests" panel in the Storybook UI gets stuck on "Starting..." and never runs tests.

The console shows:

• SB_MANAGER_UNIVERSAL-STORE_0001 (UniversalStoreFollowerTimeoutError)
• Timed out waiting for leader state for UniversalStore follower with id: 'storybook/test-provider'
• Error: Failed to start test runner process

This happens on a fresh npm install with Storybook 10.5.7. Downgrading to 10.4.6 fixes the issue completely.

Related: #33575

System

npx storybook@latest info

Additional context

• Works perfectly on Storybook 10.4.6
• The CLI test runner (vitest run --project=storybook) works fine on 10.5.7 — only the embedded UI widget is broken
• Likely a race condition: the 1-second timeout in UniversalStore follower (chunk-XYZ5NBEV.js:459) is too short on Windows

[dosubot]

@michele-ines thanks for the detailed report and the clear regression window (10.4.6 → 10.5.7). Your diagnosis looks correct: the UniversalStore follower uses a hard-coded 1-second timeout to wait for the leader's state [1], and on Windows that window can be too short for the storybook/test-provider follower to sync before the timeout fires.

A few things worth noting:

• PR #34592 (merged into 10.5.0-alpha.3) changed this code path to throw a proper UniversalStoreFollowerTimeoutError instead of a plain TypeError — that's why the error name changed between versions, but it did not increase the timeout or fix the underlying race [2].
• PR #35429 (currently open) addresses a related manager-overload issue where store events were being duplicated and the WebSocket heartbeat was wrongly closing connections. It includes deduplication fixes in boot-test-runner.ts that may reduce overall startup pressure, but it also hasn't landed yet and doesn't directly address the 1-second timeout [3].

So the root cause — the 1-second follower timeout being too short on Windows — has not been explicitly fixed in any released version.

To help narrow this down for maintainers, a couple of questions:

• From the earlier thread on #33575, one user traced a very similar symptom to a corporate security policy blocking PowerShell, which prevented Playwright from launching [4]. Can you confirm Playwright starts successfully on your machine? (npx playwright install chromium --with-deps followed by npx playwright --version)
• Is the WebSocket connection itself healthy when this happens? (Does the Storybook sidebar still update, or does the whole UI appear disconnected?)

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[FrancoKaddour]

Reproduced on Windows 10 with the public repro (Storybook 10.5.8, @storybook/addon-vitest), so I can answer the two open questions:

• Playwright starts fine — playwright --version → 1.57.0, chromium is installed and launches. This isn't the PowerShell/AV blocker from [Bug]: Storybook v10.1.11 throws error when running from Storybook Test widget in Chrome #33575.
• The WebSocket/manager is healthy — the sidebar and preview keep working (I can navigate stories) while this happens; it's specifically the storybook/test-provider follower↔leader handshake that fails, not a general disconnect.

Confirmed mechanism: on clicking "Run tests", the manager's storybook/test-provider follower waits for the leader with the hard-coded 1000ms window at universal-store/index.ts#L560-L563. But the leader lives in the Vitest runner process, and on my Windows machine that process takes ~16s to boot (spawn + Vitest + Playwright/chromium launch) — ~16× the follower's window. So the follower rejects with UniversalStoreFollowerTimeoutError ~15s before the leader is ready, which then surfaces as "Failed to start test runner process" and the panel is stuck. It's a boot-timing race, not a health problem.

The 1s window assumes the leader already exists; when it lives in a slow-to-boot external process, that's an invalid assumption rather than a health limit. Happy to send a PR making the follower timeout configurable (default 1000ms, no-op for every other store; the test-provider store passes a larger, measured value) — @valentinpalkovic, would that direction work, or do you prefer something else?

(Disclosure: I used Claude as an assistant to reproduce and analyze; the work is mine and human-reviewed.)