Issue 079: every machine named twice over, found by the large mesh bed; what running that bed cost, on 074

2026-09-22 01:13:29 +02:00
parent 446553dd1f
commit 17cc36069f
3 changed files with 55 additions and 0 deletions
@@ -47,3 +47,14 @@ its long idleness had hidden: the consumer fixture's login exceeded a backend's
 upstream artifact by bare image ID, which a registry copy cannot fetch since ADR 0096 — retired,
 since genesis installs the catalogue's builder and proves the same. The large test as a whole has
 not been run end to end; its renamed tests and the tests around them have.
 *2026-09-22.* The large mesh test was run end to end, for the first time in weeks: 12 of 25 passed.
 Everything that failed was the bed lagging the mesh, and one defect of the mesh's own. The bed now
 derives the anchor's filter after placing it on the overlay (ADR 0088), declares the ports its
 fixtures listen on, waits for an image pulled at apply, starts the hand-started host and builder
 once on a warm return, and reads the resolver modules from the catalogue instead of the example
 modules that moved there. Three more tests were retired for the catalogue beds that prove them
 (the modules resolving together and the forge, whole-mesh-novox; the cache grant, the grant bed)
 and one for what every later test proves (the hub filtered without severing the mesh). The
 defect: every machine named twice over in the files the mesh writes
 ([issue 079](../079-every-machine-is-named-twice-over/00-report.md)).
@@ -0,0 +1,32 @@
 ---
 status: resolved
 opened: 2026-09-22
 located-in: [mesh-controller internal/catalogue (facts)]
 fixed-by: mesh-controller multiple-fixes (the facts take a name as the control plane keys it, internal or bare, and write each machine once); a unit test holds both keyings to the same files
 ---
 # 079 — Every machine is named twice over in the hosts file and the resolver's zones
 ## Symptom
 The hosts file the mesh writes on every machine, and the zones file it hands a resolver, name each
 machine as `<machine>.internal.internal`, with the intended name `<machine>.internal` in the
 hosts file's second column. Names still resolve on the machine itself, because the second column
 matches, so nothing noticed. A resolver serving the zones answers for `*.<machine>.internal.internal`
 and for nothing under `<machine>.internal`, so a service named under a machine does not resolve
 from anywhere.
 Found by running the large mesh bed end to end for the first time since the mesh's knowledge became
 a fact a module asks for: its name test read the zones back. No smaller bed reads them.
 ## Why it matters beyond the instance
 Two functions agreed on a contract nobody wrote down: the caller keyed the map by the internal name,
 the facts appended the suffix to a bare one. Each was tested alone, with its own keying, and both
 passed. A file the mesh writes and nothing reads back in a test is a file that can be wrong for
 as long as it takes someone to look.
 ## What would close it
 The facts take either keying and write each machine once, held by a test that feeds both. And a bed
 reads the files back — the large mesh bed does now.
@@ -0,0 +1,12 @@
 # Diagnosis — 2026-09-22
 1. The control plane collects every placed machine's name and address for a resolution keyed by
   the internal name (`homer.internal`), because that is the map every container is given as its
   hosts. The facts that render the hosts file and the resolver's zones took the same map as bare
   names and appended `.internal` to each — their unit tests fed them bare names and passed.
 2. Fixed in the facts: a name is read as either form, and each machine is written once as
   `<machine>.internal` with its bare name beside it. A test feeds both keyings and holds the files
   equal, and holds the zones free of a doubled suffix.
 **Located in:** the facts. Not a decision. Proven by the unit test and by the large mesh bed's name
 tests, once its controller image is rebuilt from the fix.