[dustywusty]

What this changes

Follow-up to #822, as asked in review there. already_running and last_failure were synchronous Tauri commands. Tauri runs those on the event-loop (main) thread, where both waited on shell.startup, which prepare_installation holds for the whole image download. If the setup page loaded again during an install, the window froze until the download finished.

Both are now async commands that do their work in tauri::async_runtime::spawn_blocking, the same as the other commands that take the startup lock (show_openbot, the sign-in commands). They still wait for the lock, but on a blocking-pool thread, so the window keeps answering. What each returns is unchanged. The old bodies are kept as already_running_now and last_failure_now, which the existing tests call.

If the blocking task panics, already_running answers false and last_failure returns a Problem instead of failing silently.

Root cause

• Where it entered: both commands have taken shell.startup.lock() synchronously; it became a freeze when Fix fresh desktop setup and Mac sign-in #591 (2e43afd) had prepare_installation hold that lock across the image download. fix(desktop): keep the window responsive while installation holds the startup lock #822 fixed the same freeze in restore_window_on and noted these two as left over.
• How: a synchronous #[tauri::command] runs inside Webview::on_message, on the event-loop thread, so a lock held for minutes blocked the UI thread.
• Why it went undetected: the setup page calls them only when it loads, so it blocks only if that page reloads mid-install. No test sent them through IPC with the lock held.
• How this prevents recurrence: setup_page_probes_do_not_wait_on_the_event_loop_for_startup_held_by_installation holds the startup lock and sends both commands through on_message, the window's real IPC entry point. It requires on_message to return within 5 s, no answer before the lock is released, and the correct answers afterwards. With the commands synchronous again it fails (Timeout).

Where it runs

• New state that outlives a request? None. Desktop-only.
• What happens on the second replica? Not applicable.
• Anything serialised? The startup lock is unchanged; the commands now wait for it off the event loop.
• Anything fanned out to a browser? No.
• New listener, port, or schedule? No.

Boundary and audit

• Unchanged; no server code touched.

Changelog

• A line in CHANGELOG.md under Unreleased ("The desktop setup page does not freeze when it loads during an install").

Proof

• The new test failed before the change (Timeout) and passes after.
• cargo fmt --check, cargo clippy --locked --all-targets -- -D warnings, cargo test --locked --lib --bins (541 lib, 150 bin) pass on macOS arm64. Windows and Linux left to CI.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-27T22:32:58.323216Z	69e6b3d	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.