3.5 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | ||
|---|---|---|---|---|---|---|
| resolved | 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.
Resolved
2026-10-04. Hit again live the same day: a race between two pushes delivered a declaration without a just-assigned module, and removing its tools bundle stopped a workstation's apply until the next push. mesh-host#90 records what an archive unpacked: its files, the directories it made, whether the host made the target and its parents. Undeclaring removes exactly those, never a file it did not place and never a directory that was there before, and a failed removal is reported, never fatal.
An archive recorded before the change learns its list from its own bytes on the next apply while it is still declared. One already orphaned is left in place, said and forgotten. Applying an archive no longer deletes files the mesh did not place in its target directory (ADR 0030).