jschoubben
e1febe8e0f
The consolidation left a sparse sequence -- 1, 4, 6, 7, 9, 10, 12, 15, 16, 18, 19, 25, 34, 35, 36, 37, 40, 42, 44, 45, 48, 49, 58 -- where the gaps were only the archaeology of what used to be there. Renumbered contiguously. Renames run in ascending order, so every target number is already free and no two files ever collide. The reference rewrite is one simultaneous pass rather than a sequence of replacements. Numbers moved into slots other numbers were vacating -- the node host went 37 to 16 while the lab went 16 to 9 -- so replacing one at a time would have cascaded and silently pointed things at the wrong record. Seven plain-text references survived the merges as prose rather than links, naming records that no longer existed: the enrolment token, the link boundary, what a declaration is, reachability, the repository structure. Each mapped to the consolidated record that now holds it. Verified rather than assumed: every [ADR NNNN](path) link now has matching text and target, checked across the whole repository, and the checker passes. Frontmatter `consolidates:` lists dropped -- they named records that are gone, and each consolidated record already says in prose what it absorbed.
1.5 KiB
1.5 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design |
|---|---|---|---|---|
| open | 2026-08-22 |
001 — A failed package install does not fail the job
Symptom
A module declared a package. The install produced, from every mirror:
error: failed retrieving file … 404
followed by:
-> error installing repo packages
The prepare job then reported success. The package is absent; the pipeline is green.
Why this matters more than one missing package
The first thing the lab work asked the mesh to install demonstrated the exact fault the lab exists to catch — a step that failed, reported success, and left the next step to run against state that was never produced.
It is also a direct violation of a decision already taken and recorded: ADR 0023 says a step that fails must fail the job. That record notes the rule is applied instance by instance and enforced by no mechanism. This is an instance where it was never applied.
Evidence
- Observed 2026-08-22 while declaring the virtualisation package required by ADR 0009.
- A fix is written and open as a pull request, unmerged since 2026-08-20.
Open questions
- Why is the failure swallowed — is the exit status discarded, or never checked?
- Is this specific to package installation, or does the surrounding stage swallow every non-zero exit?
- The fix has been open for two days. What is the review path for a change of this class?