Sign up
View stargazers13Sign up

fix(desktop): show a starting splash instead of no window while the backend boots#23392

open2
main
GitHub fork: issue-watch/23372
opened3d agobySshivam
5 files changed
View on GitHubTwo-way sync enabledPR last imported 2d ago

Unproven: Windows. No packaged Windows build was run with user state (the bar from the #19706 revert note). Linux and macOS were.

Refs #23372

Problem

With the Local environment on, the desktop app makes no window until its backend answers the readiness check. In #23372 the backend took over 8 minutes after an update, and the app sat with no window at all. Clicking the Dock icon did nothing visible, so the only thing the user could do was quit.

Fix

The first commit re-lands #19706 by @ronak-guliani. It was reverted in #22222 only because nobody had run it on a real desktop build. The revert note asked for a fresh PR from the original commit, with before/after proof on real builds that have user state. That code is unchanged apart from a hand-resolved test conflict with current main.

Before starting the local backend, the app now shows the small splash it already used for WSL-only setups. It says "Starting T3 Code…" (WSL-only still says "Connecting to WSL…"). The splash closes when the main window first shows. With the Local environment off, nothing changes.

The second commit covers two cases the splash opened up:

  • Closing the splash (Cmd+W on macOS) while the backend was still starting left no window again, and the Dock couldn't bring one back. Activation now shows a new splash while waiting.
  • A provider sign-in return link during startup navigated the splash, because it looked up "the main window or else the first window". It now only navigates the registered main window.

Proof on real builds

Each run used a packaged build, a separate app profile, and a T3 home seeded with a trimmed copy of real user data (migrate-dev-db). To make the backend hang like in the issue, I froze its process (SIGSTOP) as soon as it spawned, launched the app again, then unfroze it. Every run except the macOS after run waited past the 60 s readiness timeout first; that one tested Cmd+W and reopen within 20 s. The main window is blurred because it shows real thread names.

Linux AppImage on Xvfb, 4x speed. Before (main at 3b95e7831b): nothing on screen for the whole wait, including after the timeout and the relaunch. The window only appears once the backend is unfrozen.

https://github.com/user-attachments/assets/0bb19e56-deb9-4392-a00a-0ba0d53a393e

After (this branch at 79185c4b5b): the splash shows at once, stays through the timeout and the relaunch, and hands off to the main window when the backend answers.

https://github.com/user-attachments/assets/1c208143-4291-4060-a33a-e607033de218

macOS arm64 app. Before (main): list_windows for the app's pid returned no windows for the whole wait and after open. The trace showed desktop.lifecycle.activate → desktop.window.activate with no window, the same spans as the issue. After (this branch at 79185c4b5b): the splash showed, Cmd+W closed it (list_windows returned no windows), and open brought a new splash back:

mac-reopened-splash

Once the backend resumed, the main window replaced it.

Run transcript
text
1Linux, main 3b95e7831b
206:15:15 backend frozen at spawn; display empty
306:16:15 "Timed out after 60000ms waiting for desktop backend readiness"
406:16:41 second launch (activation); display still has no app window
506:16:56 backend resumed -> 06:16:58 main window 1100x780 appears
6
7Linux, this branch 79185c4b5b
806:45:08 backend frozen at spawn; splash 360x220 on screen
906:46:10 after the 60 s timeout: second launch; splash still on screen
1006:46:14 backend resumed -> main window 1100x780, splash gone
11
12macOS, main 3b95e7831b
1311:53:31 backend frozen; list_windows(pid) = []
1411:54:34 after the timeout: open -> desktop.window.activate span; list_windows(pid) = []
15
16macOS, this branch 79185c4b5b
1712:16:45 backend frozen; splash window 360 wide
1812:16:51 Cmd+W -> list_windows(pid) = []
1912:16:59 open -> new splash window 360 wide
2012:17:02 backend resumed -> 12:17:07 main window 1100 wide
21
22Normal launch, Linux, first commit (not frozen):
2306:19:26.369 connecting splash shown
2406:19:28.233 backend ready
2506:19:28.283 main window created

Tests

  • The startup test from #19706 fails on main for native and dual mode and passes here.
  • New: closing the splash and then activating shows a new splash, not the main window. Fails without the activate change.
  • The provider-return test now has the splash as the first window and checks it is never navigated. Fails without the Clerk change.
  • vp run check:changed passes.

Not fixed here

This does not explain why the backend's startup recovery held a write transaction open for 658 s in #23372. The issue's trace shows the transaction's own statements finished in under 0.1 s and it closed within seconds of SIGTERM, so it was waiting on something asynchronous rather than slow SQL. I couldn't reproduce that stall. The splash only makes the wait visible, so the backend part of the issue stays open.

Re-landed, fixed and verified with Claude Opus 5.5 in Claude Code; reviewed by GPT-6.1-Sol in Codex.

🤖 Generated with Claude Code

Checks

All checks passed

Added 1 commit

  • fix(desktop): show a splash while the local backend startscaff8dd
CcoderabbitaiBot3d ago
Synced from GitHub

Warning

Review limit reached

Only developers with an assigned seat can use this organization's usage-based review budget, and seats here are assigned manually. Ask an admin to assign a seat, or change the review continuation mode in Billing.

Next included review available in 2 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 10 included reviews currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration
  • Configuration used: Path: .coderabbit.config.ts
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: b50c48c9-2708-4444-b4e7-5472ad024e7d
📥 Commits

Reviewing files that changed from the base of the PR and between 3b95e7831b11b17627dff16843bc087bfca397ec and 79185c4b5bbd5876ceaa96c490b14590b0d1cdf4.

📒 Files selected for processing: 5
  • apps/desktop/src/app/DesktopApp.ts
  • apps/desktop/src/app/DesktopClerk.test.ts
  • apps/desktop/src/app/DesktopClerk.ts
  • apps/desktop/src/window/DesktopWindow.test.ts
  • apps/desktop/src/window/DesktopWindow.ts
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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

MmacroscopeappBot3d ago
Synced from GitHub

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — The PR is a focused startup-splash fix with targeted tests, but it also changes provider authentication callback routing in a production auth path. That authentication-sensitive behavior requires human review.

You can add or adjust custom eligibility rules. Learn more.

Added 1 commit

  • fix(desktop): reopen a closed startup splash and keep provider links off it79185c4
Sshivam3d ago

@SunkenInTime could you test this on Windows? I don't have a Windows machine, and the earlier version (#19706) was reverted because Windows was never checked.

What to check on a packaged Windows build:

  1. Normal launch. A small "Starting T3 Code…" window shows for a second or two, then the main window opens and the small one closes.
  2. WSL-only mode (if you have WSL set up). The small window says "Connecting to WSL…" and hands off to the main window the same way.
  3. Slow backend. Make the backend hang at start (suspend the bin.mjs child, e.g. with Process Explorer). The small window should stay up. Launching the app again should bring it to the front, not leave you with no window.
  4. Nothing flickers, no extra window is left open, and the taskbar shows one entry.
DDara Adedeji2d ago

Tested on Windows 11 with packaged x64 builds of this PR (79185c4) and its base (3b95e78). Each run used its own copy of real user data with 86 threads.

  1. Normal launch. "Starting T3 Code…" shows for about 3 seconds, then the main window opens and the small window closes. The base build shows nothing until the main window appears.
  2. WSL-only. "Connecting to WSL…" shows, then hands off to the main window the same way. The Linux side was the installed nightly runtime, not a build of this PR. The splash itself is from this PR.
  3. Slow backend. I suspended the bin.mjs child. The small window stayed up past the 60-second readiness warning, and launching the app again brought it to the front. After I resumed the backend, one main window opened. With the base build, there was no window during the suspension or after the second launch.
  4. Flicker, leftovers, taskbar. One taskbar entry, no leftover small window, no white flash. The recordings were 30fps and dropped some frames, so they wouldn't catch a single-frame glitch. The dark loading phase in the main window happens on base too.

Closing the small window while the backend is suspended (Alt+F4) quits the app on Windows. The app kills the suspended backend itself, so nothing is left running. Launching again shows a fresh small window, then the main window.

StartingWSL-only
External imageExternal image

vp run check:changed passed, the two focused DesktopWindow/DesktopClerk test files passed (40 tests), and both Windows builds succeeded.

Not tested: the installer, the updater, macOS/Linux UI, and a live provider sign-in return during startup. The callback-routing change only has unit-test coverage here, so it still needs the auth review Macroscope asked for.

Tested by GPT-6 Astra (Codex) driving the Windows desktop, checked by Claude Opus 5.5 (Claude Code).