admin
06744dbacc
gates / gates (push) Successful in 26s
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
47 lines
2.8 KiB
Markdown
47 lines
2.8 KiB
Markdown
# records-carried — 2026-09-27 (controller v0.276.0): a restore and a drive move keep the app's records
|
|
|
|
Architecture read before any claim: `07-backup-architecture.md` §6.6 (now with "What a restore keeps"), `09` §6.4 part 10
|
|
(the conversion copy). Rows: R-697 (closed), R-700 (new; fixed, live proof open), R-691 (2) (not built — why in the row).
|
|
|
|
## Found
|
|
|
|
- **R-697 (known):** `PersistUnitRedeployConfig` built a fresh `AppConfig`, so a restore dropped `conversion_copy` — the
|
|
kept 16 datadir volume was never released. Also dropped: `desired_state` (a dead app after a restore then reads as
|
|
"unknown intent" and is not alarmed), `failed_update_step`, `last_update_undone`, `last_auto_update`.
|
|
- **Second orphan (same row):** after a restore to the OLD major the ladder converts again; `recordConversionCopy` overwrote
|
|
the first copy's record with the second's.
|
|
- **R-700 (new, by reading, not seen on a box):** `doFlipRedeploy` (drive move) persisted through the same fresh write, so it
|
|
ALSO dropped `pinned_images`. `sync.renderSource`: deployed + unpinned → the catalog copied verbatim → the next `up` runs
|
|
the catalog's newest version. Pin adoption runs only at controller start.
|
|
|
|
## Fixed (v0.276.0, controller `820e8ef`)
|
|
|
|
`carryLifeRecords` in the restore write; `earlier_conversion_copies` + a release loop over every kept copy;
|
|
`persistDriveFlip` (load-then-save, `HDD_PATH` only) + `upFromAppConfig`.
|
|
|
|
## Red-proofs (`redproofs/`, each seen failing, tree restored, suite green after)
|
|
|
|
| | pre-fix shape | failed at |
|
|
|---|---|---|
|
|
| RP1 | no carry in the restore write | `conversion_copy = <nil>` |
|
|
| RP2 | a newer record overwrites the older | `earlier []` |
|
|
| RP3 | the drive move persists through the restore write | `pinned_images = map[]` |
|
|
| RP4 | `doFlipRedeploy` back on `RedeployFromEnv` | the wiring test |
|
|
|
|
## Live (endpoint level + guest reads)
|
|
|
|
- `R/R1-9202-0.276.0.txt` — 9202 by hand, healthy. `R/R2-floor.txt` — global floor 0.276.0 (MinAgent 0.131.0), both demo
|
|
boxes on 0.276.0 within 10 s, healthy.
|
|
- `R/R3-9202-paperless-record.txt` — after the upgrade paperless-ngx keeps `conversion_copy` (16 → 18, at 09:45:15Z) and
|
|
its `.pre-update-20260927T094421Z` volume; the release job registered.
|
|
- **Night (N/):** the release on a real 18 dump — see `N/README.md` once written.
|
|
|
|
## Not proven live
|
|
|
|
- **R-700:** no Tier-0 guest has two drives (9202 has one: `scratch_hdd`). Unit-proven only; row stays WATCHING.
|
|
- **R-697's carry across a real restore:** restoring paperless now would bring it back at 16 (its unit's data is the
|
|
pre-conversion dump) and would spoil the night's release proof. Unit-proven only.
|
|
|
|
Teardown: provisioned nothing. Machine: 9202 controller image changed 0.275.0 → 0.276.0 (kept). Host: nothing. Hub: global
|
|
floor 0.275.0 → 0.276.0.
|