feat(update): lazy version check with clickable upgrade toast - #54
Conversation
- Background check after first paint, 24h cache, silent failures - Ephemeral 'New version available · Upgrade' toast, explicit click runs upgrade - Success: 'Updated · Restart to apply'; no auto-restart/forced exit - CRABCODE_FORCE_UPDATE_NOTICE preview flag, NO_UPDATE_CHECK wins - Harden install detection, detached upgrade worker, expiry redraw
Deploying crabcode with
|
| Latest commit: |
636bc91
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://059485b7.crabcode.pages.dev |
| Branch Preview URL: | https://feat-update-toast.crabcode.pages.dev |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 636bc9142c
ℹ️ 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".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if std::fs::rename(&temp_path, path).is_err() { | ||
| let _ = std::fs::remove_file(&temp_path); |
There was a problem hiding this comment.
On Windows, std::fs::rename fails when the destination already exists, so after the first update_check.json is created every later refresh silently discards the newly fetched data. Once that initial entry expires, every TUI launch performs another GitHub request and the cache timestamp/version never advances; remove or replace the destination using a Windows-compatible atomic replacement strategy.
Useful? React with 👍 / 👎.
| if path.starts_with(cargo_bin) { | ||
| let receipt = load_receipt(); | ||
| let receipt_claims = receipt.as_ref().is_some_and(|r| r.claims_path(path)); | ||
| let cargo_owns = cargo_claims(); | ||
| return classify_cargo_bin_path(path, receipt_claims, cargo_owns, use_binstall); |
There was a problem hiding this comment.
When the shell installer placed the binary under the previous $CARGO_HOME/bin (for example ~/.cargo/bin) and the user later changes CARGO_HOME, this condition is false and the receipt is never examined anywhere else. With no cargo install --list ownership record, the valid shell installation falls through to Unknown, so both the CLI and toast upgrade reject it even though the receipt identifies the install and reinstall_prefix is specifically intended to handle this environment drift.
Useful? React with 👍 / 👎.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
1 participant
Lazy background version check (24h cache, silent on failure) with an ephemeral upgrade toast.
Click Upgrade explicitly runs the upgrade. No auto-install, confirm dialog, or forced exit. Success: Updated · Restart to apply.
Verified: full suite 1498 passed, fmt clean, manual forced-toast + real upgrade from temp 0.0.11.
Merge confidence: 9/10 — merge after review. Unverified: upgrades on other package managers/platforms.