jschoubben
61f61b5d06
An audit of the six code repositories found eleven open issues fixed on main with commits and beds to show (025, 027, 033, 036, 037, 040, 045, 047, 050, 052, 053), three partly (007, 026, 035), nine not (020, 031, 041, 046, 049, 054, 064, 065, 066) and one whose fix would live outside those repos (006). Resolved ones name their evidence; partly ones say what remains; 041 records that the exposure has widened since it was reported.
2.9 KiB
status: resolved opened: 2026-09-02 located-in: [mesh-control, mesh-catalog, mesh-host] fixed-by: ADR 0051 access: mesh-controller aeb65a3, mesh-host f06eea5, mesh-catalog 69c8a5e; proven by mesh-lab assigned-catalogue-media.test.ts (sonarr and radarr share one operator-owned directory) amended-design: 02-DECISIONS/0051-shared-data-is-the-operators.md
036 — Six modules own what they must share
The symptom, as observed
Found by review of the catalogue examples (2026-09-02). The media stack is several modules — a library server, the acquisition managers, a download client and their satellites — and each of them declares the same library and download directories as its own resources.
The resolver refuses two modules that declare one path on one node, with no exemption for identical content and no merge. That rule is right in general: two owners of one path is the class of fault this repository keeps recording. But sharing those directories on one machine is the entire point of this stack — the download client and the managers must see the same downloads, the library server must see the same libraries. So the set, as written, refuses its own only sensible assignment.
No test co-resolves any two of them, which is why the manifests pass today. The first machine to be assigned the stack together is where the refusal would have surfaced.
Why it matters beyond the instance
The manifests can express a directory I own and nothing else, so a directory that is the shared workspace of several modules was written six times as six private ones. The intention — several modules, one filesystem contract between them — has no vocabulary, and this is not a media-stack peculiarity: any pipeline of modules handing files to each other on one machine (an ingest directory, a spool, a drop folder) hits the same wall.
It is also a fork in the design the catalogue has otherwise avoided: the fix could be a new owning module the others depend on, a shared-resource concept in the manifest, or a statement that co-located file handoff is not a thing the mesh supports and these modules are one module. Each answer changes what a module is, which is why this is an issue and not a patch.
Open questions
- Is the unit wrong — is a stack that must share a filesystem one module with several containers, the way the mail module already is?
- If it stays several modules: does one of them own the directories and the rest require them, and is requiring a directory from a neighbour a provision, a claim, or a third thing?
- The duplicate-path rule protects against genuinely rivalrous owners. Whatever expresses sharing must not weaken it for the cases where refusal is the right answer — what distinguishes the two, machine-checkably?
- The mesh's own rule is that a rule states how it is checked: whichever shape is chosen, what test co-resolves the stack so this class of refusal is caught before a machine is?