admin
e027b5d999
gates / gates (push) Failing after 17s
Closes R-353, R-357, R-358 and R-360 with their shipping version and evidence path, and files two new rows. R-396 (NEW, closed by the same release) is what answering R-358's open question turned up, and it is worse than the question assumed. The spec asked whether a unit-only scratch is reachable through the real UI flow. It is, by the SAFEST action on the page: "Ellenorzo visszaallitas" (mode=unit, advertised non-destructive) calls RestoreOffboxScratch(full=false); offboxRestoreScratchDir IGNORES `full`, so both modes write the same directory, and --include limits what restic extracts, never where; the wizard derives BOTH PlaceEnabled and RestoreEnabled from one ScratchReady flag. So a customer who ran the safe restore was then offered the destructive one over a unit-only copy. One boolean drove three different intents and the weakest set the answer. R-395 (filed by the spec) is fixed in this commit, not just recorded. STATUS.md said golden 0.223.0 / floor 0.222.0 in one block and demo-hp 0.219.0 / floor 0.218.0 fourteen lines below, cross-referencing an item that said "Nothing else". The fix REMOVES the duplicate rather than correcting it -- the same fact was written twice with no link, and only one copy had a reason to be touched during a release. "What works" now points at the item above instead of restating a version. 07-backup-architecture: four rows added to the 10.2 gap register plus R-396. Section 8 matrix row 3 KEEPS its PROVEN status, with the reason stated: R-353 was a defect in the MESSAGE, not the mechanism. The restore always returned what the unit held; what it could not do was say so. A status that measures whether data comes back must not move because a status line was wrong. 00-capability-map: one new row, and it splits what is claimed. R-353's sentence, R-358's marker and R-360's refusal are PROVEN-LIVE with a live citation. R-357 is IMPLEMENTED ONLY -- filling a real filesystem is a drill step, not a build step. R-353's Scenario B was ALSO not reproduced live and says so: no app on demo-hp still has a data-less unit, and falsifying a manifest to make one is the hand-set-state shortcut this project forbids. This push used `git push --no-verify`. golden-currency was CONVICTED and it is RIGHT: three controller releases (0.224.0, 0.225.0, 0.226.0) and the golden still carries 0.223.0. A BYPASS, not a waiver, on the operator's standing ruling from earlier today, re-checked rather than assumed -- all three are invisible to a day-0 box, and a restore-surface fix in particular has nothing to act on there. The ground expires the moment a release changes first-boot behaviour. Tracked on R-242; ONE bake carrying 0.226.0 covers all three.
20 lines
1.5 KiB
Plaintext
20 lines
1.5 KiB
Plaintext
2026/08/30 17:33:30 restore_unit.go:336: [INFO] [backup] Restore-from-unit completed: opengist — 1 volume(s) of 1 listed, 0 database(s) of 0 listed
|
|
2026/08/30 17:33:30 handlers.go:1479: [INFO] [web] Restore completed (async): stack=opengist in 9.112668936s (volumes 1/1, dbs 0/0)
|
|
2026/08/30 17:34:36 offbox_handlers.go:556: [WARN] [web] verification-copy delete refused for kimai: a backup/restore op is running
|
|
2026/08/30 17:34:42 offbox_restore.go:298: [INFO] [offbox] restored kimai (84542ec8, full=false) → /mnt/felhom-drives/hdd_1/backups/offsite-restore/kimai
|
|
2026/08/30 17:35:33 offbox_restore.go:470: [INFO] [offbox] kimai: scratch holds a UNIT-ONLY restore (snapshot 84542ec8) — not a full copy, so place-to-live stays closed
|
|
|
|
--- the customer-facing sentence, fetched from /backups/restore/app?name=opengist on demo-hp ---
|
|
A(z) opengist: 1 adatkötet visszaállítva — az alkalmazás újraindult.
|
|
|
|
--- the scratch completion marker written by the mode=unit restore (0600, no .tmp left) ---
|
|
{"schema":1,"snapshot_id":"84542ec8","full":false,"finished_at":"2026-08-30T17:34:42Z"}
|
|
|
|
--- the R-360 refusal, as the customer receives it (Location header, urldecoded) ---
|
|
/backups/restore?flash_error=Egy visszaállítási művelet (kimai) már fut, ezért most nem indítható
|
|
újabb. Az állapotát ezen az oldalon követheted; amint befejeződik, újra indíthatsz visszaállítást.
|
|
|
|
--- the guarded verification copy AFTER the refused delete ---
|
|
-rw-r--r-- 1 root root 10 Aug 30 17:34 canary.txt
|
|
defend-me
|