[Bug]: macOS desktop reports backend readiness failure at 60 s although the server becomes ready seconds later #26237
Description
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
Observed on 2026-10-28 (Australia/Sydney). Reproducibility from a fresh install is not established; this T3 home has a 22 GB statev2.sqlite and a 1.0 GB state.sqlite.
- Launch T3 Code (Nightly) 0.1.4-nightly.20261027.3796 on macOS (darwin arm64) against that existing
~/.t3home. - Wait on the startup screen. The app reports "The server started but did not become ready in time."
- Compare the desktop trace with the child-server log; the same backend process becomes ready about 5 s after the timeout and the app loads.
Expected behavior
A backend that becomes ready shortly after the fixed 60 s readiness budget should not be reported as a failed start. Either the budget should account for migration and recovery time on a large state database, or a late success should replace the failure state without showing a failed start.
Actual behavior
waitForHttpReady for http://127.0.0.1:3773/.well-known/t3/environment ran 60,004 ms over 67 attempts: start 11:49:21.574, timeout 11:50:21.576.
The same child process (pid 87194) logged Migrations ran successfully at 11:50:03.474 and Listening on http://0.0.0.0:3773 at 11:50:04.147. desktop.backendInstance.onReady then fired at 11:50:27.033 for runId 86e50015f96c. That process is still serving the app.
The start was declared failed at 60 s and succeeded at about 66 s. Four readiness-timeout snapshots were recorded on this machine between 2026-10-20 and 2026-10-28.
Impact
Minor bug or occasional failure
Version or commit
0.1.4-nightly.20261027.3796 (b88da91)
Environment
macOS darwin arm64, local managed backend (no WSL, no SSH environment). Existing T3 home: statev2.sqlite 22 GB, state.sqlite 1.0 GB.
Logs or stack traces
desktop.trace.ndjson (runId 86e50015f96c)
shared.httpReadiness.waitForHttpReady
baseUrl: http://127.0.0.1:3773/
requestUrl: http://127.0.0.1:3773/.well-known/t3/environment
timeoutMs: 60000, intervalMs: 100, probeTimeoutMs: 1000, attempts: 67
durationMs: 60004.121292
desktop.backendInstance.onReadinessFailure
error: Timed out after 60000ms waiting for desktop backend readiness at http://127.0.0.1:3773/.well-known/t3/environment.
desktop.backendInstance.onReady
fired 5.5 s after the failure span ended, same runId
logs/server-child.log (runId 86e50015f96c)
[11:50:03.474] INFO (#55): Migrations ran successfully
migrations: [ '70_PeerLinks', '71_PeerLinkFence', '72_WaitingLinkRequestIndex' ]
[11:50:03.567] INFO (#140): Stopping an OpenCode server left by a previous T3 Code server
{ pid: ..., port: ... }
[11:50:04.147] INFO (#6571): Listening on http://0.0.0.0:3773
backend child process failure output end
details: Timed out after 60000ms waiting for desktop backend readiness at http://127.0.0.1:3773/.well-known/t3/environment.Workaround
Wait; the backend becomes ready and the app loads. Relaunching also works, with the same startup cost.
Related
- [Bug]: Windows + WSL backend startup readiness timeout, then EADDRINUSE :3773 after relaunch #26200 reports the same readiness endpoint timing out while the backend is listening, on Windows with a WSL backend; that report also includes a separate WSL
EADDRINUSEsymptom. - [Bug]: Windows desktop exits after 60-second backend readiness timeout #4209 was closed by fix(desktop): keep probing backend readiness while the process is alive #5526, which replaced the one-shot readiness timeout with repeated probes while the backend remains alive.
- [Bug]: 26.5 GB V2 state database: thread-shell and recovery queries take 2–22 s; six indexes cut startup from ~137 s to ~17 s #22659 covered large
statev2.sqlitestartup cost and was closed with a request for scoped follow-ups for the remaining recovery-query delays. - History-wide reads saturate the single SQLite reader on large databases (thread switches take 12-50 s) #24895 reports large-database read latency after startup.
Activity
loganprit commentedon Oct 31, 2026
Confirmed another occurrence after updating the macOS desktop app to
0.1.6-nightly.20261031.3956, release tag commitd92c437baa19409f99416a44f748f148f4317c65.The desktop displayed "T3 Code could not start", "The server started but did not become ready in time", and "The server wrote no output". It offered a downgrade to
0.1.6-nightly.20261029.3892. The backend continued running and the desktop opened its main window automatically about 35 seconds after the error appeared.This occurrence identifies a specific migration that exceeded the entire readiness budget. Trace times below are UTC on 2026-10-31.
runMigrationsMigrator 73_ActiveTurnItemIndexesorchestration_v2_projection_turn_items_active_ordinal_idxorchestration_v2_projection_turn_items_active_run_idxonReadyand main-window creationThe same PID remained alive. A later read-only request to
http://127.0.0.1:3773/.well-known/t3/environmentreturnedserverVersion: 0.1.6-nightly.20261031.3956.Source at the affected release tag supports the trace:
Environment: macOS 27.0.1, build 26A434, arm64, MacBookPro18,2, 32 GiB RAM. Local desktop-managed backend, no WSL or SSH involved in this startup. The existing
statev2.sqlitefile was approximately 16 GiB. The triage CLI version was also0.1.6-nightly.20261031.3956; the affected desktop version was independently checked from its app bundle and the live endpoint.Observed once during this update. No fresh-install or repeat-launch reproduction was attempted. No application restart, downgrade, configuration change, or direct database write was performed during triage. The migration completed successfully and the app recovered without intervention.
This appears to be the same misleading 60-second failure described here, with fresh evidence that migration 073 alone can exceed that budget on an existing large database. A screenshot of the failure dialog is available for the reporter to attach.
Prepared by the Codex agent via
t3 triageusing 6.1 Sol.