runtime-host: intermittent 'stopped responding during startup' after a Windows upgrade over an existing profile

[Joob1n]

On the Windows upgrade-lifecycle check, the app installed by an upgrade intermittently fails to start: its own stderr reports

[runtime-host] fatal: Error: Runtime Host stopped responding during startup
    at runtimeHostStartupError (…/app.asar/node_modules/@maka/runtime-host/dist/client/startup-error.js:25:20)
    at RuntimeHostDesktopManagerImpl.connect (…/dist/main/runtime-host-desktop-manager.js:317:19)
    at async RuntimeHostReconnectLifecycleImpl.start (…/reconnect-lifecycle.js:62:45)

and the renderer never mounts, so the packaged smoke times out.

Observed: run 32324991998 on #3241, step Exercise pinned-version upgrade and uninstall. The sequence that failed: the pinned 0.1.9 baseline installed and verified clean → upgraded to the current 0.1.11 build → the upgraded app's Runtime Host stopped responding during startup. The standalone smoke of the same 0.1.11 build passed minutes earlier in the same job, so the build starts fine against a fresh profile.

What makes the upgrade path different: the lifecycle deliberately reuses one isolated HOME and user-data directory across both versions — that is the point of an upgrade test — so the 0.1.11 Runtime Host starts against whatever state 0.1.9's run left under that HOME (host socket/lock/config). Whether the hang is caused by that leftover state or is an unlucky cold-runner slowdown is exactly what the log cannot yet say: the fatal is a client-side startup timeout, and the Host process's own stderr is not captured in the verifier output.

Attribution note: this surfaced through #3241's new CDP diagnostics (the app wrote DevToolsActivePort, the poll named the bound port, and the endpoint never answered — which is what pointed at the main process rather than the port plumbing). Some of the historical did not expose CDP within 30 seconds failures in this step may share this cause, but that cannot be established retroactively from the old logs.

Suggested next steps:

1. Capture the Runtime Host child's stderr (or its log file) into the lifecycle verifier's failure output, so a startup hang is attributable to the Host's own last words rather than the client's timeout.
2. Reproduce locally: install 0.1.9's profile state, then start a current build against it, in a loop.
3. If leftover state is the trigger, the fix likely belongs in Host startup's handling of a predecessor's socket/lock remnants.

Not caused by #3241 (verifier-only changes); filed separately so the product-side question is trackable.

[Joob1n]

Claiming the verifier half (capturing the Host's own stderr/log into the lifecycle failure output); the reproduction and any Host-side fix I will attempt after the open release-verifier PRs land.

[liugddx]

New occurrence with app-side evidence, and a scope widening: this reproduces on a fresh install with a fully isolated profile, not only after an upgrade over an existing profile.

Run 32380815350 (release-windows-check, head 83ba1fd), step "Verify the Windows release", stage "smoking the packaged renderer" — the very first packaged launch in the job: freshly installed candidate, isolated --user-data-dir, isolated HOME/APPDATA/LOCALAPPDATA. The harness (with the newly added stderr capture from #3327) reports:

Error: Packaged Maka renderer did not expose CDP within 90 seconds: The operation was aborted due to timeout.
[runtime-host] fatal: Error: Runtime Host stopped responding during startup
[startup] fatal: Error: Runtime Host stopped responding during startup

Mapping to source: host_unresponsive from connect-or-spawn.ts — the election loop saw an endpoint but it never became responsive within DEFAULT_ELECTION_DEADLINE_MS = 45_000, then sawUnresponsiveEndpoint selects host_unresponsive (connect-or-spawn.ts:340). With an isolated fresh profile there is no pre-existing endpoint to inherit, so the unresponsive endpoint was created by this same app instance's own spawn on a heavily loaded runner.

Two implications for whoever picks this up:

1. The earlier bare "did not expose CDP / fetch failed" failures on the Windows lanes (at least four across feat(windows-sandbox): implement production-identity readiness probe #3161/feat(release): verify Windows automatic updates end to end #3240/feat(win): Abort-path installer rollback with backup retention #3265 heads) are plausibly this same product-level startup failure — the harness could not see app stderr until now, so they were attributed to CDP attach. The capture is in place going forward, so future occurrences will self-identify.
2. The 45s election deadline plus a wedged named-pipe endpoint on a slow runner is enough to kill startup outright (the app exits rather than retrying the spawn). Whether the right fix is a longer deadline, a respawn-on-unresponsive retry, or endpoint health hygiene is a product decision — but the failure is user-visible (app fails to launch), not just CI noise.

Evidence grade: run log + source read (connect-or-spawn.ts:37,340, startup-error.ts:52); not locally reproduced.

[liugddx]

Status after #3382 and the latest #3265 Windows run:

• fix(desktop): drain untracked Runtime Host before update #3382/windows: auto-update silently fails when a Runtime Host process survives the app quit (installer cannot clear it) #3340 is a distinct update-handoff process-lifetime bug and is now closed; it should not be treated as resolving this startup issue.
• Release Windows check 32477989412 on feat(win): Abort-path installer rollback with backup retention #3265 exact head 68520adc completed cleanly in 23m21s. It launched packaged Maka repeatedly across clean release smoke, pinned-version upgrade, automatic update/relaunch, rollback, recovery reruns, and uninstall. No host_unresponsive occurred in that run.
• This is one useful non-occurrence, not resolution evidence. The fresh-isolated-profile failure already recorded here means predecessor state is not a necessary trigger.

Recommended next product investigation:

1. Run a repeated fresh-profile startup stress loop under CPU/disk pressure while capturing the execution candidate/Host child's stderr, exit status, endpoint publication time, first successful pipe response, and election deadline.
2. Classify the failing cut before changing timeouts: child exited, child alive with a published-but-unresponsive pipe, or stale endpoint/registration observed by election.
3. If retry is added, bind it to the exact manager-owned candidate/Host identity and prove cleanup before respawn; do not turn the 45s deadline into an unbounded wait or hide the fault with verifier retries.

The verifier already preserves app-side fatal output, so future occurrences should stay attributable to this issue.

中文：最新 #3265 Windows 全链路多次启动均通过，本轮未复现 host_unresponsive，但单次未复现不能关闭问题；全新 profile 已证明旧状态不是必要条件。下一步应做带 Host 子进程 stderr/退出码/pipe 时间线的压力复现，先定位 child exit、活着但 endpoint 无响应、还是 election 观察到 stale endpoint，再决定是否做有身份约束的单次 respawn。

[liugddx]

@Joob1n I am starting a narrow product-side diagnostic slice for #3279 from current main, avoiding the verifier surface you previously claimed.

Scope:

• preserve candidate/Host child stderr + exit/endpoint/election timing as bounded structured startup evidence;
• add a repeated fresh-profile startup stress entry point for Windows;
• do not increase the election deadline or add retry/respawn until the failing cut is classified;
• no changes to the release verifier's existing CDP/process-probe ownership unless a product diagnostic needs a minimal read seam.

I will post the exact branch/PR and evidence before proposing a behavior fix. Please flag any active overlap and I will rebase the ownership boundary rather than duplicate work.