jschoubben
3c535ead31
161 resolved and verified on a machine: the workstation runs a host the mesh compiled, published, delivered and started, applying declarations and reporting the version it was delivered as. The system it was built for comes from the artifact — the one thing a toolchain takes from a module, which 0142 already allowed because the target is a property of the artifact. The version comes from where the binary sits, which 0142 decided and nothing had implemented. Two mistakes on the way, both caught by reading the output rather than the line that claimed success. A second -ldflags does not merge with the first: the binary gained its system and lost -s -w, 12.2MB against 8.5MB. And the delivered binary was named after its package, so the first delivery was correct, reported success and was invisible to the launcher. A delivered host that cannot apply is a machine the mesh cannot repair, because the declaration that would fix it is the one it cannot apply. The launcher's fallback is what made that an inconvenience instead of an expedition. 162 is new and not about the host: an archive has no removal, so a module using one can never be unassigned, and the attempt takes the whole apply with it — the machine applies nothing else either. It is how undoing the first delivery froze the workstation.
2.7 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |
|---|---|---|---|---|---|
| located | 2026-09-30 |
|
162 — An archive cannot be undeclared, and trying stops the machine applying anything
What was observed
2026-09-30, unassigning the host module from the workstation to undo a delivery.
holding this machine: 0 applied, and map[apply:applying "mesh-host.next": no way to remove a "archive"
0 resource(s) were applied and remain; everything was attempted, so what is not listed as failed was done.
Nothing was applied at all — not the archive, not the other forty resources that had nothing to do with it. The machine stopped reconciling and stayed that way until the module was assigned again.
Why it matters
Every other resource kind can be taken away. A file is removed and what was found under it is put back; a container is stopped and removed; a unit is given back the state it was found in (ADR 0118). An archive has no removal at all, so:
- a module with an archive can never be unassigned — the attempt fails for ever;
- the failure takes the whole apply with it, so the machine applies nothing else either, and one unassignable resource is a machine frozen against every other change;
- it is silent in the mesh's terms: the push reported sent, and only the machine's own journal says what happened.
The host module is the obvious case and not the only one. An archive is for what inlining cannot serve — a theme, an icon set, a tree of configuration — and any module using one is in the same position.
What the right answer probably is, and the question in it
The other kinds answer this by remembering what they found. An archive unpacks many files into a directory the mesh did not necessarily create, so removal has a real question in it: remove what the archive put there, or remove the directory? The first needs the applier to have recorded the file list; the second would delete whatever else lives there — and for the host's own versions directory, that is every other delivered version.
Recording what was unpacked is the answer that matches how the rest of the host behaves, and it is what issue 126 and ADR 0118 already argue for elsewhere: the mesh gives back what it found.
How a fix is checked
A module with an archive is assigned, pushed, unassigned and pushed again; what the archive put on the machine is gone, anything that was in the directory beforehand is still there, and the apply that removed it applied everything else in the same declaration.