ui-kit: diagnose a browser-session startup timeout after workspace refresh

Start with scripts/visual.mjs, which passes all selected projects to one Vitest run, and packages/ui-kit/vitest.config.ts, which defines the fine, coarse and mixed Chromium projects. The Vitest BrowserSessions.createSession code in dist/chunks/cli-api.CnMVyzaz.js waits for both connected and ready callbacks. Done means a bounded control that records both callback timings, the effective connection timeout and first-test start, and identifies which callback is missing when the timeout fires.

Out of scope

Changing #1938's navigation-paint correction, raising browser connection budgets, weakening network/font guards, removing projects, or treating a later pass as a diagnosed fix.

Context

During #1938 / PR #1964 validation, local candidate 750f39f517a7a8c3ab424754edb920f5aee95233 (tree 39ad61f03c570424c80d5132331068f1474cd856, based on main f2e0fcee7de537c26e218bbc0b7c508c54da76b6) failed before test execution in the pinned offline Playwright 1.63.0 container. The command selected rail-fine/coarse/mixed and the overlay-stacking.pointer / destination-press.pointer files. Vitest 4.1.11 reported Failed to connect to the browser session for rail-mixed after 61.41 seconds: six files selected, zero tests executed, one unhandled error. All three projects logged dependency re-optimization because the lockfile changed, followed by dependency scan/bundle messages. This sequence does not establish a cache, resource or WebSocket cause.

The checkout had just integrated the published 0.43.1 workspace metadata and the #1966 motion-diagnostics harness. Install, build and local preflight pass. A subsequent unchanged-source isolated rail-mixed overlay-stacking run executes and passes all 139 cases (39.68 seconds); it is startup recovery evidence, not a correction or a complete combined-project receipt. Prior full hosted candidates for #1938 pass, but do not diagnose this newer local startup failure.

Source entry points verified at main 9355d1bd6ec91915e07aff184080bd48bb85fc2c:

• (const schedulingArg, scripts/visual.mjs:71) defaults browser file parallelism to false; (if (inside), scripts/visual.mjs:84-102) passes all selected projects and repeated file filters to one Vitest invocation. Preserve the original explicit offline container setup; the outer wrapper does not universally select network isolation for rail projects.
• (const railProject, packages/ui-kit/vitest.config.ts:82-103) defines fine/coarse/mixed Chromium projects and their pointer/reduced-motion settings.
• Installed Vitest 4.1.11, dist/chunks/cli-api.CnMVyzaz.js:459-489 (BrowserSessions.createSession), waits for both connected and ready callbacks before clearing the connection timer. The error alone does not distinguish a missing connection from missing readiness. The fallback timeout is 60,000 ms when browser.connectTimeout is unset. Inspected bundle SHA-256: a236001d048380e2c67d05423fc9ea3f26b07ee019ba8d6e622082f29d49102e.

The original text log is retained separately from recovery logs. These are source findings, not a reproduction or diagnosis. No production or harness change is selected.

Scope

Reproduce or control the browser-session startup boundary with the recorded source and project selection. Collect native browser/process, server/WebSocket, dependency-optimizer and startup observations before selecting any correction.

Acceptance criteria

• Preserve the initial no-test failure and exact source/command/runtime identities.
• Establish the responsible startup condition with a bounded source/environment control, distinguishing optimizer completion, browser launch/navigation, each session connected/ready callback and first test execution. Retain the resolved effective connection timeout and timestamps for both callbacks; the generic error cannot identify which callback was missing.
• Any correction has a meaningful failing-first/restored mutation and successful original combined project selection; preserve current guards, budgets and all projects.

Verification

Recreate the recorded pinned, offline three-project invocation and collect startup diagnostics without replacing the network/font guards. Keep isolated and combined recovery receipts distinct from reproduction or correction evidence. Complete selected hosted proof for any eventual correction.

Contract impact

None selected. This is a local test-startup investigation with needs: repro; no implementation or release commitment is selected. Priority p2 reflects wanted, unscheduled verification work without evidence of release-blocking urgency.

Bounded combined recovery — 2026-10-15

After the isolated 139-case control, one unchanged-source repeat of the original three-project/two-file selection executes and passes all 837 cases (129.08 seconds). No cache deletion, budget change, guard relaxation or source edit was performed between the failed startup, isolated control and combined recovery. This recovers current-task verification; it does not reproduce or diagnose the original browser-session connection failure, establish a cache/resource cause, or select a correction. The failed zero-test attempt remains retained. Keep needs: repro and the startup observation requirements above.

Triage clarification — 2026-10-15

Retain needs: repro: an available next investigation is to capture the two startup callbacks and their surrounding process/optimizer events in the recorded three-project setup, then establish a bounded causal control. The existing 837-case combined pass is recovery evidence only; another unchanged green run would not close this gap. Source inspection above supplies a more precise diagnostic boundary without selecting a cause or changing budgets.

The deliverable fits verification epic #736, but its native relationship currently has the documented maximum of 100 direct children. Leave this issue standalone rather than removing/reparenting existing work or inventing another epic; discovery during #1938 does not make its navigation-paint outcome the parent of this independent startup investigation.

Original-candidate fresh-cache control — 2026-10-15

A distinct instrumented fresh-cache control uses actual reported candidate 750f39f517a7a8c3ab424754edb920f5aee95233 and its own frozen installation/full build, with generated Vite cache absent before launch. The original offline three-project/two-file selection passes all 837 tests in six files, exit 0, 90.40 seconds. Temporary callback and first-test logging preserves the 60,000ms effective session budget, runtime readiness conditions and every assertion.

All three initial sessions connect in 970.61–976.68ms and become ready in 1516.80–1520.55ms, then resolve. Initial optimizer bundles/metadata finish at 10:29:19.210–19.467Z; first overlay test hooks execute at 10:29:22.124–22.339Z, after those callbacks and bundles. Native Chromium/optimizer processes are retained. Unlike the preceding main control, this cache is genuinely fresh; unlike the historical failure, it does not recreate an existing cache invalidated by the publication/lockfile transition. No causal cache/resource/WebSocket conclusion follows.

Retain needs: repro and no agent-ready: the original cache/lockfile-refresh state and failing callback/process timeline remain missing. The successful source-matched cold startup is an additional control, not a repair or a reason to discard the zero-test failed receipt. No stale-cache simulation or additional repeated invocation was run. Native parent remains absent with #736 at the verified 100-child limit.

2026-10-15 triage: folded the source-matched fresh-cache startup timeline into the body, preserving original failure, recovery identities, budgets and classification.

Reconstructed publication-cache transition — 2026-10-15

A further bounded control warms the original three-project/two-file selection on pre-publication candidate 3eead90e89c4ccbdedbf70b377a461cde138bcf2, then refreshes the same disposable checkout to reported candidate 750f39f517a7a8c3ab424754edb920f5aee95233. All 775 generated cache files survive checkout, frozen installation and the new source build byte for byte. The lockfile changes eighteen workspace versions from 0.43.0 to 0.43.1; external entries are unchanged.

All three refreshed projects actually log lockfile-triggered re-optimization. Saved optimizer metadata changes lockfileHash from 92a734b4 to a33ace57 with unchanged configHash 1b39dd30. Both invocations pass all 837 cases in six files, exit 0 (134.81s warming; 134.27s refreshed). Refreshed connected callbacks arrive in 2743.46–2808.39ms, ready in 4029.33–4036.39ms under the unchanged 60,000ms budget; native launch/navigation/WebSocket, optimizer, first-test and process observations are retained.

This reconstructs a real cache/lockfile refresh, not the unknown historical cache/process/order/host state. No failed startup boundary or cause is established. Retain needs: repro, existing classification and no agent-ready; the original failed receipt and causal criteria remain required.

2026-10-15 triage: added the instrumented publication-cache transition control, preserving the historical failure and remaining reproduction gap.

2026-10-16 triage at main ed6b0c5f09ada1b6f899bf245f3f1b176352bf77: Refreshed the railProject declaration pointer to its actual line 82; the installed runner/startup callback evidence, original failed receipt and cache-transition controls retain their original identities. The failing connected/ready/process timeline is still required. Keep needs: repro; no additional unchanged browser invocation or timeout change was made.