felhom-controller/REPORT.md

REPORT — controller v0.80.0: disk card shows + acts on the stable path

Baseline

• felhom-controller main @ 9596c8e, v0.79.0 → v0.80.0. Trunk-based, main.
• Follow-up to v0.78.0 (stable-path registration) + v0.79.0 (registered badge on stable path).

Problem (operator-reported, screenshot)

The storage disk card still displayed each external drive's raw host PVE mount /mnt/<name> (usb · /dev/sdc1 · /mnt/felhom-flash). Inside the guest/controller the drive lives at the stable path /mnt/felhom-drives/<name> (the agent's guest_path) — which is what the registry, app HDD_PATH, and FileBrowser use; the raw path doesn't even exist in the guest. Two latent bugs rode on the same mismatch: the Leválasztás/Törlés buttons posted the raw path, so handleStorageEject/handleStorageWipe would unmount the drive but RemoveStoragePath(raw) would miss the stable registry entry (orphan); and the impact warning /api/storage/impact?where=raw found no apps (HDD_PATH is the stable path).

Fix

controller/internal/web/templates/settings.html (disk-view JS):

• Card sub-line now shows regKey(d) (= d.guest_path || d.mount_path) — the stable in-guest path.
• actions() passes the stable path to confirmEject/confirmWipe (handlers map it to raw for the agent via agentWhere() AND deregister the stable registry entry). registerDrive keeps the raw mount_path (its agent guest-attach operates on raw; handleStorageRegister maps to stable).
• confirmEject/confirmWipe derive the type-to-confirm name from the basename (where.split('/').filter(Boolean).pop()) so it still equals the server's path.Base(where) check when where is the stable path.

controller/internal/web/storage_handlers.go (handleStorageWipe):

• The agent eject now uses agentWhere(req.Where) (was req.Where verbatim), matching handleStorageEject. So a stable registered path maps to the raw mount for the agent while RemoveStoragePath(req.Where) deregisters the stable entry. Agent op is the identical raw path as before; only the registry bookkeeping is corrected. The format step is unchanged (keyed on device).

Agent-facing operations (eject unmount, format) produce the IDENTICAL raw paths/device as before — only the controller's display + its own registry bookkeeping/impact lookups now use the stable path.

Tests

• go build ./... && go vet ./... && go test ./... — all green (incl. TestTemplatesParse).
• handleStorageWipe's new mapping rides on agentWhere, already covered by TestAgentWhere (stable→raw, raw idempotent). JS changes covered by template parse (no JS unit harness — existing pattern).

Deploy (v0.80.0 → guest 9201)

• (filled at deploy) built+pushed :0.80.0 on 192.168.0.180; deployed to 9201; :0.80.0 Up (healthy).

Verification

• (filled at verify) disk card sub-line shows /mnt/felhom-drives/felhom-flash (+usb); the rendered eject/wipe button onclick args carry the stable path; "Regisztrálva" intact; 2 connected.
• NOT live-clicked: the destructive eject/wipe buttons (would unmount/format the demo drives). Verified the path-mapping logic by inspection + the agent ops are unchanged (raw via agentWhere/device).

Observations (recorded, NOT acted on)

• pendingActivationDrives still keys off the agent's raw MountPath (the "~30 mp újraindítás" banner); obsolete in the live-activating intermediary model — key off GuestPath/BoundUnderParent or retire.
• Free-form settings storage-add (handlers.go) registers a user-typed path verbatim (advanced flow).