Skip to content

[Bug]: Desktop stops probing backend readiness after the 60s budget, leaving "Connecting to WSL…" stuck forever even though the backend becomes healthy #5522

Description

@lgwacker

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

  1. Windows 11 + WSL2, enable WSL backend only in Settings > Connections.
  2. Launch the desktop app under a slow WSL cold boot (server bundle loading over /mnt/c, Defender re-scanning freshly installed files, or right after an app update relaunches).
  3. Wait on the "Connecting to WSL…" splash.

Expected behavior

The desktop should keep probing readiness while the backend process is still alive. When the backend eventually becomes healthy (it can take 70–80s+ over the WSL/Windows filesystem bridge, and even longer right after an update), the app should connect — or at minimum surface an error and a recovery path instead of an indefinite splash.

Actual behavior

The readiness probe is one-shot: DesktopBackendManager.runBackendProcess (apps/desktop/src/backend/DesktopBackendManager.ts:566) forks a single waitForHttpReady call with a fixed 60s budget. When that budget expires, onReadinessFailure only logs, and nothing ever probes again — even though the child process stays alive and becomes healthy ~20s later. The "Connecting to WSL…" splash spins forever with no retry and no error. This is exactly the failure documented in #4535 (73–81s boot against a 60s budget), and it is worst on the first launch after an update (cold Windows file cache + Defender re-scan push the boot well past the budget).

The backend is fine — it starts, listens, and answers HTTP 200 continuously; nothing is listening for it anymore.

Impact

Blocks work completely

Version or commit

main @ abc1234 (reproducible on 0.0.28+; readiness code unchanged since)

Environment

Windows 11 x64, WSL2 (Ubuntu 24.04), T3 Code desktop app, WSL backend only

Logs or stack traces

"httpReadiness.timedOut",{"baseUrl":"http://172.31.213.87:3773/",
 "requestUrl":"http://172.31.213.87:3773/.well-known/t3/environment",
 "timeoutMs":60000,"attempts":54,
 "lastFailure":{"cause":{"_tag":"BackendTimeoutError",
 "message":"Timed out waiting for backend readiness ..."}}}

The waitForHttpReady span times out at exactly ~60s, exits with BackendTimeoutError, and never probes again. Meanwhile server-child.log shows the backend "Listening on http://0.0.0.0:3773" ~20s after the probe gave up.

Workaround

Restarting the app repeatedly until a warm/cached boot fits inside the 60s window; or stage the server bundle on ext4 and bind-mount it over /mnt/c (see #4535).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions