Today
crates/app/src/main.rs opens the data directory, checks for a migration and starts the local kernel before the gpui event loop runs. Any failure goes to exit_with_startup_failure, which opens an empty window, raises a system-level Critical prompt (window.prompt, "Tcode could not start") and exits the process when it is dismissed. The failures that reach it: the data directory is in use by another Tcode process (store/db.rs), a relocation of an older data directory is blocked (store/relocate.rs), the migration check fails, or the local kernel does not start.
Expected
The window opens as usual and the application draws the failure itself: the local host is shown as unavailable with the reason, with Retry (take ownership again after the other instance quits) and Quit, and attaching to a remote machine stays possible. The code already runs the window without a local kernel in two cases (the migration window, and a window attached to a remote host while the local kernel merely stays alive), so a failed local kernel start is one more attachment failure, not a process-level error. Only when the window itself cannot open does the system dialog remain.
Limits
When the data directory cannot be opened, settings cannot be read, so that window uses the default language and theme; the notice says so.
Owner
The startup path in crates/app/src/main.rs and the client's attachment-failure surface in crates/ui. Principle 2 applies: the client renders the host state it was given, here "no local host, because …". Not part of #535; scheduled after A7 (#643) with the follow-up fixes.
Today
crates/app/src/main.rsopens the data directory, checks for a migration and starts the local kernel before the gpui event loop runs. Any failure goes toexit_with_startup_failure, which opens an empty window, raises a system-level Critical prompt (window.prompt, "Tcode could not start") and exits the process when it is dismissed. The failures that reach it: the data directory is in use by another Tcode process (store/db.rs), a relocation of an older data directory is blocked (store/relocate.rs), the migration check fails, or the local kernel does not start.Expected
The window opens as usual and the application draws the failure itself: the local host is shown as unavailable with the reason, with Retry (take ownership again after the other instance quits) and Quit, and attaching to a remote machine stays possible. The code already runs the window without a local kernel in two cases (the migration window, and a window attached to a remote host while the local kernel merely stays alive), so a failed local kernel start is one more attachment failure, not a process-level error. Only when the window itself cannot open does the system dialog remain.
Limits
When the data directory cannot be opened, settings cannot be read, so that window uses the default language and theme; the notice says so.
Owner
The startup path in
crates/app/src/main.rsand the client's attachment-failure surface incrates/ui. Principle 2 applies: the client renders the host state it was given, here "no local host, because …". Not part of #535; scheduled after A7 (#643) with the follow-up fixes.