updater.rs

2026-05-27 — unified state machine (rewrite, Owner spec)

Previous design had three half-aligned UX paths: Settings page showed text in the page, tray menu and startup auto-check both showed osascript dialogs. Symptoms in production:

1. Settings "Check for updates" button spun forever with no progress feedback while a 400 MB download ran silently in the background (the v1.7.5 incident — user thought it hung).
2. State surfaces never agreed: clicking tray then opening Settings would not show "downloading 35%", it would show idle.
3. updater.check() had no hard timeout — an unreachable endpoint pinned the whole pipeline indefinitely.

Rewrite (Owner spec, 2026-05-27): single Rust state machine, three UI entry points all feed it, three UI surfaces all mirror it via the updater:state event.

State machine:

Idle → Checking → UpToDate { current, checked_at }
              ├─→ Available { version, notes? }
              │     └─→ Downloading { downloaded, total?, percent? }
              │           └─→ Installing { version }
              │                 └─→ Ready { version }  → user clicks Restart → app.restart()
              └─→ Failed { stage, error } (from any stage)

Key invariants:

• Auto-install (Q1=A in design): once Available is reached the pipeline downloads + installs without asking. The "ask" is the Ready banner at the end. By the time the user sees the banner the bytes are already on disk — restart is instant.
• 250 ms progress throttle (Q3): without it, ~16 KB-per-chunk callbacks on a 400 MB bundle emit ~25 k events and wedge the IPC / WS channel.
• 30 s check timeout: the v1.7.5 incident proved reqwest's default infinite connect timeout is too generous. After 30 s the pipeline transitions to Failed{stage:"check"} and the UI stops spinning.
• Reentrancy guard: a tokio::sync::Mutex::try_lock around the pipeline so a second click while one is in flight is a no-op, not a queued duplicate run.