Issue 152 is fixed: a lookup failure is no longer an absence

The three gatherers pass over a node whose set does not compose, and
raise anything else. 151 stays open: this removes the false reasons a
roster changes, not the fact that a real change still replaces every
container.
This commit is contained in:
2026-09-29 23:26:20 +02:00
parent 72eaf52867
commit 3c2b4fc6b6
@@ -1,9 +1,9 @@
---
status: located
status: resolved
opened: 2026-09-29
located-in:
- mesh-controller cmd/mesh-controller/plan.go (routeNamesInTheMesh skips a node whose plan will not compose)
fixed-by:
fixed-by: mesh-control fix/152-a-lookup-failure-is-not-an-absence
amended-design:
---
@@ -94,7 +94,21 @@ The codebase already states the rule this breaks, forty lines away, about the sa
> A lookup failure is an error, never "not found": collapsing the two composed a declaration without
> the trust whenever the inventory hiccuped, delivered by a push that reported success.
## How the fix is checked
## How it was fixed, and how the fix is checked
A test that composes the roster with one node's plan failing, and requires the compose to fail rather
than return a roster missing that node's names.
`planFor` now marks the two failures that really are a statement about the node — its set not
composing, and a setting that reaches nothing — and the three gatherers pass over those and only
those. Every other failure is raised, naming the machine and the read.
Five tests hold it: a set that cannot compose is marked as the node's own; a store that cannot be
read is *not*; one incoherent node still does not cost the rest their names; a roster is never
returned beside an error; and the raised failure names what could not be read.
The two sibling gatherers were audited and fixed the same way — the grant composer, which would have
withheld a consumer's credential, and the private-network membership, which would have taken a
machine off the overlay. Three other `planFor` callers were audited and left alone: they refuse or
report rather than silently withdraw, which is the safe direction.
**This does not close [issue 151](../151-a-new-name-recreates-every-container-in-the-mesh/00-report.md).**
A roster that changes for a real reason still replaces every container in the mesh. This removes the
false reasons; whether the roster belongs in a container's identity at all is that record's question.