[shivamhwp]

A managed desktop backend can become ready just after the 60-second limit. The app opens "T3 Code could not start" even though that same process goes on to serve the app seconds later.

Give startup three minutes before reporting a readiness failure. Successful probes still open the app immediately, and crash-loop recovery still triggers on the third restart. A stuck server takes two extra minutes to show recovery diagnostics. This changes the wait, not database startup performance.

The reporter used macOS arm64 with a local managed backend. The corex recording exercises the same probeReadiness and DEFAULT_BACKEND_READINESS_TIMEOUT in apps/desktop/src/backend/DesktopBackendManager.ts, which has no macOS branch. Windows and WSL use this manager too. Web and mobile clients do not launch this backend.

Closes #26237

Evidence

Current head d3febc3cf443ddad7a8076b9ea538adf9249b20e merges main into the recorded head. apps/desktop/src/backend/DesktopBackendManager.ts and its test are byte-for-byte unchanged from 21cefe874af40566bf0ab3c1b49c7af3a769613a. The readiness and recovery flow shown below is unchanged, so these recordings still cover the fix. CI on the current head reran all 9 manager tests successfully.

Packaged Linux x64 desktop on physical corex, version 0.1.3, Electron 44.9.3. Before is full main dac8b11ddc25bd5da62a367fdb6c3de777ae2986; after is recorded PR head 21cefe874af40566bf0ab3c1b49c7af3a769613a.

These are release AppImages built with vp run dist:desktop:artifact --platform linux --target AppImage --arch x64, with source maps disabled. Each run has a separate disposable T3 home and Chromium profile. The packaged code and assets are unchanged. The test pauses the real managed server child for 70 seconds with SIGSTOP, then resumes that same PID with SIGCONT. Readiness probes, authentication, and the client all run normally. No development server or mocked readiness endpoint is involved.

Main showed recovery at 63.411 seconds, then that same child became ready and the app connected at about 76 seconds. The PR head became ready at 79.339 seconds without reporting failure or showing recovery. These are elapsed capture times, not a startup performance comparison.

Main at 68 seconds	PR head at 100 seconds

Before:

before.mp4

After:

after.mp4

The continuous recordings include launch, the wait past 60 seconds, and the connected app. The terminal at the top is the test console with build and process observations. The original 22 GB database workload was not recreated.

Validation

• At the head above, all 9 DesktopBackendManager.test.ts tests passed on corex. The regression covers readiness at 66 seconds without failure, no failure at 179 seconds for a stuck backend, and failure reporting at 180 seconds. Existing crash-loop coverage passes.
• vp run check:changed passed at this head before publication. Required GitHub checks pass, with path-filtered jobs skipped.
• Independent GPT-6.1-Sol code review has no open findings. Comment nit R1 was fixed in this head. Macroscope requests human review of the longer wait before recovery feedback.

Build and runtime output

Both builds passed on Boat, attempt 1, default machine, t3code template, exit 0:

• Main: j_5rj2rt4p4olftj2kgmak, VM bx_3c25fru6, commit dac8b11ddc25bd5da62a367fdb6c3de777ae2986.
• PR head: j_e3pach3iilhnur6wooqg, VM bx_xjdspeb5, commit 21cefe874af40566bf0ab3c1b49c7af3a769613a.

AppImage SHA-256 values were verified after download on corex:

main b6676768e46aad223d3a32a6700367d82c114c635543e55766ab8678b2496601
head 92ec258d98213ea07aad14f86b7c17f572d6f8d4706db41aaad70b92f62bc2e7

Each recording uses a dedicated Xvfb display on corex and an isolated home, with --password-store=basic. No other desktop windows or account state are present. Main's recording is 113.13 seconds; the head's is 116.13 seconds. Both are continuous H.264 MP4s at 1280 × 960, 15 fps.

Before, times since recording setup:
0.313s main baseline build
0.815s launched packaged AppImage pid=3808094
3.355s paused real managed backend for 70 seconds pid=3808452
63.411s recovery window shown
73.434s resumed same managed backend pid=3808452
75.637s managed backend ready
75.638s client window created

[12:33:59.658] INFO (#1): bootstrap backend start requested
[12:34:59.681] WARN (#189): backend readiness check failed during bootstrap
[12:34:59.713] INFO (#178): startup recovery window shown
[12:35:11.852] INFO (#189): backend ready
[12:35:11.900] INFO (#189): main window created

After, times since recording setup:
0.347s PR head build
0.851s launched packaged AppImage pid=3789368
6.330s paused real managed backend for 70 seconds pid=3789605
76.334s resumed same managed backend pid=3789605
79.339s managed backend ready
79.540s client window created

[12:30:17.571] INFO (#1): bootstrap backend start requested
[12:31:30.494] INFO (#191): backend ready
[12:31:30.607] INFO (#191): main window created

Focused test output at recorded head 21cefe874af40566bf0ab3c1b49c7af3a769613a:

 Test Files  1 passed (1)
      Tests  9 passed (9)
   Duration  14.04s

Implemented by Claude Opus 5.5 through Claude Code. Reviewed and verified by GPT-6.1-Sol through the Codex harness in T3 Code.

[macroscopeapp]

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — The desktop backend gets three minutes rather than one to become ready before timeout-based recovery reporting. Human review is required for this product-default change and its tradeoff between accommodating slow startup and delaying recovery feedback.

No code changes detected at d3febc3. Prior analysis still applies.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: issue-watch/26237
• File: .coderabbit.config.ts
• Commit: 21cefe8
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 9a2b405a-309d-4cdb-ad3e-f54918702442

Commits

Reviewing files that changed from the base of the PR and between 93a9e07 and 21cefe8.

Files selected for processing: 2

• apps/desktop/src/backend/DesktopBackendManager.test.ts
• apps/desktop/src/backend/DesktopBackendManager.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 remain after this review.

Walkthrough

The desktop backend readiness timeout increases from one minute to three minutes. A timing test checks late readiness and confirms that a backend still unavailable after three minutes reports a startup timeout.

Changes: Backend readiness

Layer / File(s)	Summary
Readiness window and timing tests apps/desktop/src/backend/DesktopBackendManager.ts, apps/desktop/src/backend/DesktopBackendManager.test.ts	The default readiness timeout increases to three minutes. Tests verify that readiness after 66 seconds does not report a startup failure and that continued unavailability through 180 seconds reports a timeout.

Priority: Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Low

Possibly related issues

• pingdotgg/t3code#23372 describes a desktop backend that remains unready during startup recovery. This change extends the readiness window but does not address startup that exceeds three minutes.
• pingdotgg/t3code#26200 reports a WSL backend readiness timeout. This change extends the same readiness window, but does not address the separate port-release race.
• pingdotgg/t3code#23877 reports readiness timeouts during slow cleanup and startup. This change extends the timeout but does not address the reported post-start issues.

Possibly related PRs

• pingdotgg/t3code#21780: Adds desktop startup behavior that waits for backend readiness; this PR changes the readiness timeout used by that flow.
• pingdotgg/t3code#25903: Reports backend startup failures through recovery when the backend misses readiness; this PR changes when that failure can occur.
• pingdotgg/t3code#26063: Handles WSL startup failures tied to backend readiness; this PR extends the desktop manager’s default readiness window.

Suggested reviewers: t3dotgg, juliusmarminge, macroscopeapp

Merge Risk: Minimal · up to 21cef

The longer startup window allows slow backends more time to become ready. No merge-blocking risk remains.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main change: extending desktop backend startup time before showing recovery.
Linked Issues check		Issue #26237 asks that a backend that becomes ready shortly after the fixed 60 s readiness budget not be reported as a failed start. It allows either a larger budget or a late success that replaces th…
Out of Scope Changes check		The reviewed diff between merge base df4132b and head 21cefe8 changes only two files. DesktopBackendManager.ts changes one constant, a…
Description check		The description is detailed and covers the problem, implementation, scope, linked issue, verification results, evidence, limitations, and test outcomes. It uses “Evidence” and “Validation” instead of …

Full details: Linked Issues check

Explanation

Issue #26237 asks that a backend that becomes ready shortly after the fixed 60 s readiness budget not be reported as a failed start. It allows either a larger budget or a late success that replaces the failure state. The change at head sets DEFAULT_BACKEND_READINESS_TIMEOUT from Duration.minutes(1) to Duration.minutes(3) in apps/desktop/src/backend/DesktopBackendManager.ts. The new test in DesktopBackendManager.test.ts covers the reported case: a backend that returns 503 until 66 s and then returns 200 produces no startup failure report. The same test shows a never-ready backend produces no report at 179 s and the failure report at 180 s. Per-request timeout, probe interval, and crash-loop handling are unchanged in the diff. The issue's stated database startup cost is not reduced. The issue does not require that. Related reports #26200 and #24895 are contextual and are not coding requirements of this PR. Non-coding verification (macOS fixture, recordings) does not affect this verdict.

Full details: Out of Scope Changes check

Explanation

The reviewed diff between merge base df4132b and head 21cefe8 changes only two files. DesktopBackendManager.ts changes one constant, and adds a comment that explains the new value. DesktopBackendManager.test.ts adds one regression test for readiness timing at 66 s, 179 s, and 180 s. Both changes directly implement the readiness-budget objective in #26237. No unrelated code, configuration, or dependency changes appear in the reviewed diff. The PR description references images and recordings, which are not repository changes.

Full details: Description check

Explanation

The description is detailed and covers the problem, implementation, scope, linked issue, verification results, evidence, limitations, and test outcomes. It uses “Evidence” and “Validation” instead of the template headings and does not explicitly quote maintainer approval, but the required information is otherwise substantially present.

Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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