felhom-controller/REPORT.md

REPORT — FileBrowser no-op recreate fix (F2) + drop restic binary (F1)

Repo: felhom-controller · Version: v0.81.0 → v0.82.0 · Date: 2026-06-24 Baseline: main @ 036a6078b (CHANGELOG top v0.81.0), trunk-based, no branches.

Two findings from TEST-REPORT-stable-path-sysdrive-restart-2026-06-23.md, both validated at source.

F2 — gate the FileBrowser recreate on an actual change

Root cause: syncFileBrowserMounts (internal/web/handlers.go) ran docker compose up -d --force-recreate --remove-orphans unconditionally. The existing sourcesChanged flag gated only the restore-mode DB reset (down -v); the force-recreate fired on every controller restart and every storage sync even when config.yaml/compose were byte-identical — bouncing the customer's file-access UI, contradicting the "Vezérlő újraindítása → apps keep running" promise (the 3.4 reproduction in the test report).

Fix:

• Capture oldConfig/oldCompose from disk before the writes.
• Re-read finalConfig/finalCompose after the writes — so the integrations' ReapplyConfigForTarget("filebrowser") edits to config.yaml are included in the comparison.
• New pure helper fbNeedsRecreate(oldCfg, newCfg, oldCompose, newCompose) bool (byte-equality on both files) drives the decision. changed → up -d --force-recreate --remove-orphans; otherwise a plain up -d --remove-orphans (ensures running, no bounce).
• Preserved: the restore-mode DB reset stays gated on sourcesChanged && resetDBOnChange; when it runs it sets changed = true (a down -v removed the container, so it must be recreated).
• First-ever run (no old files → empty bytes) differs from generated content → changed = true → creates it.

Files: internal/web/handlers.go (helper + gate; added bytes import).

F1 — drop the unused restic binary from the image

controller/Dockerfile: removed the restic \ apt line and its # - restic: … comment. Disk-tier restic moved to the host agent; no controller code execs the binary. Left untouched (still live in the dashboard/UI): ResticSchedule config, migrateResticToRsync settings migration, and the Method/backup-dir-name string references.

Tests

• Added TestFbNeedsRecreate (internal/web/filebrowser_gate_test.go): unchanged → false (no recreate); config differs → true; compose differs → true; first run (no old files) → true.
• Red-proof: hard-wiring fbNeedsRecreate to always return true (the old unconditional behaviour) makes the "unchanged → no recreate" case fail; restoring the byte-equality gate turns it green.
• Web package top-level tests: +1 (added TestFbNeedsRecreate).
• Green gate: go build ./... ✓ · go vet ./... ✓ · go test ./... ✓ (all packages ok).

Deploy & verify (guest 9201 / felhom-pve)

Deployed via the golden bootstrap mechanism: docker pull …:0.82.0 into the guest, set /etc/felhom-controller-image → 0.82.0, systemctl restart felhom-controller-bootstrap.service.

• docker ps → gitea.dooplex.hu/admin/felhom-controller:0.82.0 Up … (healthy) ✓
• F1: docker exec felhom-controller command -v restic → NO-RESTIC ✓
• F2 (no-op): deploying 0.82.0 restarted the controller; its startup sync logged FileBrowser sync — no config/compose change, ensured running without recreate (3 storage path(s)), and FileBrowser StartedAt stayed 2026-06-23T18:15:47 (UNCHANGED — not bounced) ✓
• F2 (change path): dirtied the on-disk config.yaml + restarted the controller → log FileBrowser mounts synced (recreated) — 3 storage path(s), config updated, FileBrowser StartedAt advanced to 2026-06-24T09:05:53 (recreated on a real change) ✓. The sync regenerated config.yaml back to canonical (test line gone), FileBrowser + controller healthy — state restored.

Method: invoked the exact server-side sync (controller restart → syncFileBrowserMounts) on the live guest; no browser tool needed for this check (it's container-lifecycle, observed via docker inspect).