Before submitting
Area
apps/desktop
Steps to reproduce
- Windows 11 + WSL2, enable WSL backend only in Settings > Connections.
- 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).
- 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).
Before submitting
Area
apps/desktop
Steps to reproduce
/mnt/c, Defender re-scanning freshly installed files, or right after an app update relaunches).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 singlewaitForHttpReadycall with a fixed 60s budget. When that budget expires,onReadinessFailureonly 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
The
waitForHttpReadyspan times out at exactly ~60s, exits withBackendTimeoutError, and never probes again. Meanwhileserver-child.logshows 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).