[verified] Clear update availability after successful apply #34
Loading…
Reference in a new issue
No description provided.
Delete branch "astaranix/clear-applied-update-availability"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
last-availablemarker.current, so later failed checks or early apply failures cannot resurrect an already-applied update.test,boot,switch, status-write retries, and newly discovered candidates.Root cause
Bash
${2:-$(last_available_event)}treats an explicitly empty argument as missing. Success callers already passed an empty event to clear availability, but the writer silently reinserted the old hash. The Rust Details observer correctly interpreted that nonempty marker as an available candidate. The live status file showed exactly this contradiction:current, successful apply, empty changed inputs, and a retained candidate hash.Verification
bash tests/status-history.sh scripts/nixos-updater.shbash tests/transactional-apply.shpython3 tests/build-progress.py(5 passed)aarch64-linux:package,shell-tests,module,tray-rust-package, andtray-rust-no-default-tests.--no-write-lock-file --override-input nixpkgs github:NixOS/nixpkgs/ffb3c9b700e759be2ef13237c9d8f953b32a1e46; localflake.lockwas not changed or committed.Scope
Source fix only: no live update/check, activation, restart, or status-file rewrite was performed. No Rust or legacy C++ production changes.
## Summary - Honor the explicit empty candidate event written by successful apply and no-change check/apply outcomes instead of restoring the old `last-available` marker. - Remove the consumed candidate cache after publishing `current`, so later failed checks or early apply failures cannot resurrect an already-applied update. - Preserve candidate availability on genuine check/build/activation failures and retries; keep reboot reminders and canonical check/apply history intact. - Extend status-history lifecycle and transactional apply regressions, including `test`, `boot`, `switch`, status-write retries, and newly discovered candidates. ## Root cause Bash `${2:-$(last_available_event)}` treats an explicitly empty argument as missing. Success callers already passed an empty event to clear availability, but the writer silently reinserted the old hash. The Rust Details observer correctly interpreted that nonempty marker as an available candidate. The live status file showed exactly this contradiction: `current`, successful apply, empty changed inputs, and a retained candidate hash. ## Verification - Watched the successful-apply regression fail before the fix, then pass. - Watched the later-failure resurrection regression fail before cache cleanup, then pass. - `bash tests/status-history.sh scripts/nixos-updater.sh` - `bash tests/transactional-apply.sh` - `python3 tests/build-progress.py` (5 passed) - Bash syntax, ShellCheck, and staged whitespace checks. - Real Nix builds/checks passed on `aarch64-linux`: `package`, `shell-tests`, `module`, `tray-rust-package`, and `tray-rust-no-default-tests`. - Packaged Rust tests: 202 passed with default features; 80 passed without default features. The two existing opt-in real telemetry tests remain ignored. - Nix validation used `--no-write-lock-file --override-input nixpkgs github:NixOS/nixpkgs/ffb3c9b700e759be2ef13237c9d8f953b32a1e46`; local `flake.lock` was not changed or committed. ## Scope Source fix only: no live update/check, activation, restart, or status-file rewrite was performed. No Rust or legacy C++ production changes.