fix(desktop): keep probing backend readiness while the process is alive

[lgwacker]

What Changed

runBackendProcess (apps/desktop/src/backend/DesktopBackendManager.ts) now probes backend readiness in a loop while the child process is still alive, instead of probing exactly once with a fixed 60s budget and then never retrying.

Each round gets a fresh readiness budget; on timeout, onReadinessFailure fires and the loop immediately starts another round; the loop stops on success or is torn down with the run scope when the child exits. Behavior is unchanged when the backend becomes ready within the first budget.

Why

The readiness probe was one-shot: after the 60s budget expired, the app never probed again even though the backend process kept running and became healthy ~20s later. A slow WSL cold boot (server bundle loading across /mnt/c, or a first launch right after an update — cold Windows file cache + Defender re-scan) routinely exceeds that budget, so wsl-only users were left stuck on the "Connecting to WSL…" splash forever with no retry and no recovery path. This is the failure documented in #4535 and filed as #5522. It makes the app resilient regardless of how long boot takes, without widening the budget or changing the fast-path.

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Fixes #5522

---

Note

Medium Risk
Changes desktop backend startup and readiness signaling; behavior is covered by a new test but repeated timeouts could increase log/snapshot noise until the backend is healthy.

Overview
runBackendProcess no longer treats backend HTTP readiness as a single attempt with one timeout. It loops waitForHttpReady in a scoped fiber until the health endpoint returns success or the child exits.

Each iteration gets a fresh readiness budget. A timeout still invokes onReadinessFailure, then probing continues instead of stopping permanently—addressing slow WSL cold boots that outlast the first budget while the backend process keeps running.

Fast paths are unchanged when the backend becomes ready within the first budget. A new test asserts re-probing across multiple expired budgets before a late 200 response.

^{Reviewed by Cursor Bugbot for commit 22821ba. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix runBackendProcess to keep probing backend readiness while the process is alive

Previously, runBackendProcess stopped probing after the first readiness timeout. It now loops, calling waitForHttpReady repeatedly across successive timeout budgets until the backend responds with HTTP 200, invoking onReadinessFailure on each failed attempt and onReady once on success. A new internal effect desktop.backendProcess.probeReadiness encapsulates a single probe attempt and returns a boolean to drive the loop.

^{Macroscope summarized 22821ba.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c2acd4a3-ef2b-4d40-a8f5-cd618a2a72d6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This bug fix changes backend readiness probing from one-shot to continuous retry, which modifies core startup behavior. The fix is well-tested and localized, but the author is new to this area of the codebase and the change affects backend lifecycle management - warrants human review.

^{You can customize Macroscope's approvability policy. Learn more.}