Issues 303, 304; 240 resolved, 242 located

303: a media server's previews were reached through a link its container never mounted — fixed by mounting them. 304: settings set replaces the whole layer with nothing to read it first and no history. 240 is fixed by mesh-controller#47; 242 has backups running and records what the rollout taught. (First opened as 245 and 246; main has since taken both numbers, and 302 was the last.)
2026-10-08 01:45:39 +02:00
parent 08a874b55f
commit 67599df951
2 changed files with 84 additions and 0 deletions
@@ -0,0 +1,39 @@
+---
+status: resolved
+opened: 2026-10-05
+located-in: [mesh-media-catalog modules/plex]
+fixed-by: mesh-media-catalog#2
+amended-design:
+---
+
+# 303 — A media server's previews were reached through a link its container never mounted
+
+## What was observed
+
+On the home server the media server's scrub previews — 423 GB, about 57 000 preview files, one per
+video — had not grown in seven months: the newest was from the day its preview folder was moved off
+the server's own disk onto the large storage pool. The server's log repeated, live, that it could not
+create a directory under its preview folder.
+
+## Why
+
+The move left the preview folder as a **symbolic link** inside the server's configuration directory,
+pointing at the pool. The container mounts the configuration directory and the media libraries, and
+not the pool's path, so inside the container the link pointed at nothing: the server could neither
+show the previews it had nor make new ones, and said so only in its own log. Nothing the mesh reports
+showed it — the container ran, and answered.
+
+It is the failure the mesh's rule against symbolic links exists for: a link resolves differently in
+every place that reads it, and a container is such a place.
+
+## Resolution
+
+The previews are a directory of the module, mounted at the server's preview path; where that
+directory lives on a machine is the machine's placement setting, here the pool path the files were
+already in. The link was removed at the cutover, the container recreated, the preview folders visible
+inside it again and the log's errors gone. The previews are not backed up, by the operator's choice.
+
+## How it is checked
+
+The catalogue check that every mount is declared passes over the module. On the machine: the preview
+folder seen from inside the container lists the same folders as the pool path.
@@ -0,0 +1,45 @@
+---
+status: open
+opened: 2026-10-05
+located-in: [mesh-controller cmd/mesh-controller (settings), mesh-controller internal/inventory (SetSettings)]
+fixed-by:
+amended-design:
+---
+
+# 304 — Setting a module's settings replaces the whole layer, and nothing shows it first
+
+## What was observed
+
+An operator's agent set one placement — where a media server's preview folder lives on one machine —
+with `settings set <module> {"places": {…}} --node <machine>`. The command answered that the setting
+was recorded. The machine's plan then mounted the server's configuration from an empty default
+directory: the node's layer had held the placements of three other directories, eight media
+accesses, a public exposure, four endpoints and the account's ids, and every one of them was gone.
+
+Caught before any push, by reading the plan. The previous layer was read back from the controller
+database's nightly dump — the backups that issue 242 asked for, a few hours old.
+
+## Why
+
+The layer is a statement of the whole, by design (the inventory's `SetSettings`: "replacing rather
+than merging … removing a key is done by leaving it out"). That design is sound; what is missing
+around it is everything that makes it safe to use:
+
+- **There is no way to read a layer.** `settings` has `set` and `clear`, no `show`; the console verb
+  likewise. To change one key, a person must already know every other key in the layer.
+- **There is no history.** The row is updated in place; the previous values exist nowhere but a
+  database backup.
+- **The answer does not say what was dropped.** "places" was reported as set; the six keys removed
+  were not mentioned.
+
+## What would fix it
+
+1. A way to read a layer — `settings show <module> [--node]` and the same on the verb.
+2. `set` answers with what changed: keys added, changed and **removed**, so dropping one is never
+   silent. A removal could even require saying so.
+3. The previous value kept: a settings history row per change, so an undo needs no backup.
+
+## Status
+
+Open. Until it is fixed: read the layer (from the store, read-only) before setting it, and compare
+the node's plan before and after.