# REPORT — felhom-controller v0.46.0: fix /backups 500 (stale disk-tier template fields)

**Repo:** `felhom-controller` · **Version:** 0.46.0 · **Date:** 2026-06-12

## v0.46.0 — /backups 500 fix (most recent)

**Symptom:** `GET /backups` → HTTP 500 ("Internal error").

**Diagnosis (from the live controller log, not source-guessing):**
`backups.html:64: executing "backups" at <.Backup.RepoStats>: can't evaluate field RepoStats in type
interface {}`. Not a panic / not a funcmap nil-deref. The 8C de-privileging slimmed `FullBackupStatus`
to app-data-only (DB dumps + Docker-volume tars); the disk-tier restic/cross-drive backup moved to the
host agent. But `backups.html` still carried the pre-8C restic UI, referencing `.Backup.X` **struct
fields that no longer exist**: `RepoStats, LastBackup, ResticSchedule, NextBackup, PruneSchedule,
Retention, SnapshotHistory, LastCheckTime, LastCheckOK`. While those fields existed-but-nil, the
`{{if .Backup.X}}` guards short-circuited; once removed from the struct, the field access itself errors.
(Root-level keys like `.PerDriveRepoStats`/`.Tier2DriveGroups`/`.ResticPassword` are map lookups → nil
on miss → safe; the `Tier1*/Tier2*` fields are on `AppBackupRows`, which the handler still supplies — so
the user's "Tier2/cross-drive fields are consistent" was correct; the break was the `.Backup.*` restic
stats only.)

**Fix (template-only, no Go change — the struct was already correct):** removed the dead disk-tier UI
from `backups.html`, keeping the app-data backup view — storage overview (DB dumps), DB-dump status card
+ schedule + table, per-app backup rows (Tier1/Tier2 via `AppBackupRows`), restore. Removed: the restic
"Mentési tároló"/"Tároló méret"/snapshot-history/per-drive-repo-stats/integrity/retention blocks, and
the restic schedule rows. The status card + schedule summary now key on `.Backup.LastDBDump`.

**Validation (guest 9201):** built + deployed `felhom-controller:0.46.0`; `GET /backups` → **HTTP 200**,
renders all sections (Tárhely áttekintés / Adatbázisok / Ütemezés), no template error in logs.
`TestTemplatesParse` + `TestSortDisksForView` green; golden rebaked to 0.46.0.

`settings.html`'s `.ResticSchedule`/`.LastCheckTime` are unaffected (root-map lookups, nil-safe; the
latter is the self-update checker, not backup).

---

## v0.45.0 — storage UX polish (order, init filter, register shortcut, clarity) · pairs with **felhom-agent v0.24.0**

Part B of the storage-fixes spec — controller-side ordering/filter/clarity polish on top of v0.44.0's
role-aware drive management. (Part A, the eject role-gate, lives at the agent — see felhom-agent
v0.24.0 / its REPORT.)

## What changed

### B1 — deterministic disk order (`internal/web/agent_disk_handlers.go`)
`agentDisksListHandler` sorts the agent's drive list server-side before rendering (`sortDisksForView`):
**user-data → system → backup** (then unrecognized), alphabetical by storage name within each tier.
The agent's storage view iterates an unordered Go map, so the list previously reordered on every reload
(CLAUDE.md lesson #3). A stable Go-side contract beats relying on map order or template JS.
Test: `TestSortDisksForView`.

### B2 — init wizard excludes mounted drives (`templates/storage_init.html`)
The `formattable` filter gained `&& !d.mount_path` (matching the attach wizard): an already-mounted
drive (e.g. `felhom-usb`) no longer appears as an "initialize" candidate. Eject it first to make it an
init target.

### B3 — register shortcut for a mounted-but-unregistered user-data drive
- New `POST /api/storage/register` → `handleStorageRegister` → reuses `registerStoragePath` (the
  manual-add path): records the existing mount into the `StoragePath` registry (no format, no eject),
  then FileBrowser-syncs. `AddStoragePath` dedupes (clean error on double-register).
- `settings.html`: a mounted, **unregistered** user-data drive now shows **Regisztrálás** as its
  PRIMARY per-card action; Leválasztás/Törlés stay secondary.

### B4 — system-storage clarity (presentation only, `settings.html` + `style.css`)
`local` and `local-lvm` are both kept (not collapsed). Each card now carries:
- a plain-Hungarian **purpose description** keyed on the agent's `type`/`role` (`purposeDesc`):
  local-lvm → internal SSD (system, Docker, app **databases**); local → host storage, **no app data**;
  pbs → backups; user-data → external store for large app files.
- an **app-backing tag** (`appBackingTag`): `local-lvm` → "Alkalmazás-rendszer"; user-data →
  "Alkalmazás-adatok".
- a one-line **tiering note** above the list answering "which storage do the apps use?".
Role/type stay authoritative from the agent — no agent contract change.

### B5 — eject confirmation names affected apps
Already wired pre-existing: `confirmEject` → the type-to-confirm modal fetches `/api/storage/impact`
and lists, by name, the deployed apps that lose their storage (parity with the wipe warning). Verified,
no code change needed.

## Build / deploy
- Built `felhom-controller:0.45.0` on the build server (`build.sh 0.45.0 --push`).
- Deployed to **guest 9201** on `felhom-pve`: `docker pull`, updated `/etc/felhom-controller-image`,
  re-ran `felhom-controller-bootstrap.sh` → container recreated on `0.45.0`, **healthy**;
  `[selfupdate] Current version 0.45.0 is up to date`.
- CHANGELOG (newest on top) + `controller/README.md` (Storage Management section) updated.

## Live validation (guest 9201, auth disabled on this demo → API reachable)
- **B1 order:** `GET /api/disks` returns `[felhom-usb(user-data), local(system), local-lvm(system),
  felhom-pbs(backup)]` — **stable across 3 reloads** (user-data first, system alpha, backup last).
- **B2 filter:** the only user-data drive (`felhom-usb`) has a `mount_path`, so the new filter excludes
  it from init candidates (confirmed by the live disk data).
- **B3 register:** `POST /api/storage/register {where:/mnt/felhom-usb}` → `{registered:true}`;
  `settings.json` now lists `/mnt/felhom-usb` (label "Tárhely (felhom-usb)", schedulable);
  `FileBrowser mounts synced — 1 storage path(s)`.
- **B5 impact:** `GET /api/storage/impact?where=/mnt/felhom-usb` → `{apps:[], where:…}` (valid wiring;
  no deployed app currently routes data there).
- **B4 clarity:** pure presentation rendered client-side from the agent's role/type (templates
  parse-tested; the disk data carries the keys the JS branches on). Visual confirmation is a browser
  check.
- `go test ./...` green for the whole module.

## Golden rebake — DONE
- Rebaked on `felhom-pve` (the gitea registry allows anonymous pull — no creds needed):
  `bash /root/build-golden.sh 9100 local:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst local-lvm local
  vmbr0 gitea.dooplex.hu/admin/felhom-controller:0.45.0`.
- Verified the build guest baked `/etc/felhom-controller-image` = `…/felhom-controller:0.45.0` and the
  docker image `…/felhom-controller:0.45.0` before archiving.
- Golden archive: `local:backup/vzdump-lxc-9100-2026_06_12-09_53_03.tar.zst` (876 MB). Transient build
  guest 9100 stopped + `pct destroy 9100 --purge`'d. New provisions now bring up controller 0.45.0
  directly (self-update still covers any later drift).