jschoubben
5cac268457
Correcting design 26 to match what the merged code does, and fixing issue 112's status, which used a word the vocabulary does not have. A claim on a seat the manifest does not itself declare is refused at registration rather than by the parser. A module may hold a seat another module declared — that is why ADR 0126 has a caller name the seat and not its provider — so whether the name exists is a fact about the whole catalogue. And a declared seat may promise nothing. That is a marker seat, and most node-scoped seats are markers: which module is this machine's packet filter. ADR 0126's "a declared seat carries a protocol" says what a holder must satisfy, not that every seat offers something. `records.py` still fails on ADR 0120 resting on a proposed ADR 0112, which is not this branch's and not mine to decide.
2.8 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| resolved | 2026-09-24 |
|
|
112 — Adopting a tunnel gives the mesh the peers' addresses but not their names
What was observed
On the control-node, 2026-09-24, reading what the resolver would answer before it was assigned.
The predecessor's resolver answers for four machines — the hub and the three that reach it over the tunnel. The mesh's would have answered for one: itself. The other three are carried peers of the tunnel the hub took over (ADR 0105) — the mesh holds an address for each, and keeps it, and has no name for any of them, because a name comes from enrolling and they have not enrolled.
Taking the resolver in that state replaces a file that resolves four machines with one that resolves one, and — because the resolver is told the mesh's suffix is its own and forwards nothing under it — the other three stop resolving rather than falling through. Everything on the machine that reaches another by name breaks at once: the predecessor's own agents, its pipeline, anything an operator typed.
Why it matters beyond this instance
Adoption was designed so that what the mesh does not know yet, it leaves alone. The tunnel is the first place the mesh takes over something whose content is knowledge the predecessor has — three machines exist, and these are their names — and it takes the addresses without the names. Nothing says so; the mesh reads as complete.
This is an ordering rule the migration did not have: a name the predecessor answers for must keep resolving until the machine behind it is a node. It applies to the resolver first and to anything else derived from "the machines the mesh knows" while the mesh knows fewer than the machine does.
Open questions
- Should a carried peer be nameable — the operator saying which machine a carried address is, before it enrols — so the resolver can answer for it in the meantime? The mesh would be recording a name it cannot verify.
- Or should the resolver simply not be taken until every carried peer has enrolled, stated as a refusal rather than a note in a runbook?
- Or should the mesh's resolver, while any peer is carried, forward the suffix it cannot answer to the resolver it replaced — which is the adapter shape (ADR 0104) applied to names instead of routes?
- What checks it? Nothing compares what the predecessor's resolver answers with what the mesh's would.