Module self_update 

In-place binary upgrade for atomcode.

Flow:

1. Fetch latest.json manifest (version + per-target sha256/size).

2. Detect current platform and pick the matching binary entry.

3. Verify we can write to current_exe()’s directory — if not, fail with a precise message telling the user to re-run with sudo.

4. Download the binary to a sibling temp file, streaming progress.

5. Verify SHA256 against the manifest. Bail (and delete temp) on mismatch — we never touch the live binary until verification passes.

6. Three-way swap to replace the live binary: a. atomcode → .atomcode.rolling (Windows allows renaming a running exe) b. new binary → atomcode (install the upgrade) c. best-effort: remove old .bak, then .atomcode.rolling → .bak

   Steps a–b are the critical path; step c is best-effort. If the old .bak is locked (AV scanner, still-running process, read-only attribute), the upgrade still succeeds — the .rolling file lingers and is cleaned up on the next upgrade attempt.

Rollback swaps the live binary with .bak in place, so one backup always points to “the other version” — the user can toggle by alternating /upgrade and /upgrade rollback.

Structs

AppliedUpgrade

Successful apply result — fed into the re-exec handoff so the new process can render a one-time “✓ Upgraded” banner on the welcome screen.

BinaryEntry

Manifest

PendingUpgrade

Pointer record stored at ~/.atomcode/staged/pending.json. Describes a downloaded binary that hasn’t yet been promoted to live. Lifecycle: written by prepare_deferred_upgrade, read (and deleted on success / incremented on failure) by apply_pending_upgrade.

RollbackSummary

UpgradeSummary

Enums

UpgradeEvent

Streamed progress events from the upgrade/rollback machinery.

Constants

ALREADY_LATEST

Sentinel substring in the “already latest” error so the CLI/TUI layer can render a calm informational message instead of a scary red error. Kept as a plain string to avoid an error-type refactor.

DOWNLOAD_BASE

MANIFEST_URL

Functions

apply_pending_upgrade

Bootstrap entry point: called once at the very top of main() BEFORE the tokio runtime, TUI, or any heavy init. Three outcomes:

backup_path

Sibling path used to stash the previous binary.

binary_filename

Release artifact filename for a given version + target, matching what scripts/release.sh publishes to dist/<version>/.

binary_url

current_exe_path

Path of the running atomcode executable. Resolved once at the start of an upgrade so we know what to replace.

detect_target

Return the target tag used in release artifact names (darwin-arm64, linux-x64, windows-x64, …).

ensure_writable

Return Ok(()) iff we can create a file alongside exe.

fetch_manifest

Fetch and parse latest.json.

fetch_manifest_if_newer

Quiet variant of check_latest used by the hourly background poll. Returns the remote (version, manifest) only when strictly newer than current_version. Separate from version_check::check_latest because that one only gives back the version string; here we need the full manifest to know the per-target sha256 / size.

prepare_deferred_upgrade

Download + verify a new release into staged_dir() without touching the live binary. Writes pending.json as the final step so a partial download (crashed mid-stream) doesn’t masquerade as “ready to apply” — the pointer only appears if sha256 passed.

re_exec_self

Replace the current process with a fresh invocation of the live binary, preserving argv, cwd, and env. On Unix this is execv (same PID, old process image gone). On Windows we spawn a child and exit the parent — a separate PID, but terminal stdio is shared so the user still sees one continuous “session” from their perspective.

read_pending

Read pending.json if present. Absent file → Ok(None). Corrupt JSON returns an error so callers can delete it and retry; apply_pending_upgrade does exactly that.

run_rollback

Three-way swap between the live binary and .bak, leaving .bak pointing at what was previously live. Calling rollback twice in a row returns you to the original state — intentional, so users can toggle between last-two versions without redownloading.

run_upgrade

Top-level upgrade driver.

staged_dir

~/.atomcode/staged/ (or equivalent on Windows). Created on demand by prepare_deferred_upgrade; safe to treat as possibly-missing at read time. Kept under the same root as history / recent_dirs so nothing new appears in $HOME.