A failed in-app update can leave the desktop app without its backend #954

Problem

On Windows and Linux the in-app update swaps folders with two renames: backend/ to backend.old, then the new backend/ into place. If the second rename failed (an antivirus or indexer holding a handle on the fresh files for more than about 1.5 seconds), the install was left with no backend/. On the next launch the leftover sweep deleted backend.old, which by then was the only copy of the app. The install needed a full re-download.

Who is affected: desktop users on Windows (mainly) and Linux, from the first in-app update after a full install. The 0.21.0 upgrade itself is a full download and does not go through this swap.

Related: #141 (the same kind of two-step swap, for the runtime pack).

Where

• desktop/src-tauri/src/main.rs:1513 rename_with_retry (retry budget)
• desktop/src-tauri/src/main.rs:1543 rename_all_or_restore (undo on failure)
• desktop/src-tauri/src/main.rs:1747 the update swap runs its renames through it
• desktop/src-tauri/src/main.rs:1155 sweep_update_leftovers, called at launch from main.rs:534

Current state

Fixed in PR #891 (merged into big-release, ships with 0.21.0).
Not yet run on Windows with a scanner really holding a handle; the unit tests cover a failing rename on a temp folder.

Proposed fix

What the merged fix does:

• The update's renames run in order. When one fails, the ones already done are undone, newest first, so a failed swap leaves the previous install exactly as it was.
• The launch sweep keeps backend.old while there is no backend/app, because then it is the only copy.
• The rename retry budget is about 5 seconds (34 tries, 150 ms apart) instead of 1.5 seconds. A missing path is not retried, since waiting never fixes it.

Verification

• cargo test --manifest-path desktop/src-tauri/Cargo.toml a_failed_backend_install_puts_the_previous_backend_back
• The same for a_failed_exe_install_puts_the_previous_backend_and_exe_back and the_launch_sweep_keeps_backend_old_when_it_is_the_only_backend.
• Optional, on Windows: hold a file open inside the staged backend during an update, then confirm the app still starts on its previous version.