Issues 214–216: a plan losing its own controller, a module pinned silently, a bundle never delivered #333
@@ -0,0 +1,36 @@
|
|||||||
|
---
|
||||||
|
status: open
|
||||||
|
opened: 2026-10-03
|
||||||
|
located-in:
|
||||||
|
- mesh-controller
|
||||||
|
fixed-by:
|
||||||
|
amended-design:
|
||||||
|
---
|
||||||
|
|
||||||
|
# 214 — A plan loses track of the controller it rebuilds, and waits on it for ever
|
||||||
|
|
||||||
|
## What was observed
|
||||||
|
|
||||||
|
2026-10-03, a merge to the controller's repository planned three tiers: the controller itself, then
|
||||||
|
the build agent, then the route proxy. The controller's build finished and was recorded at 19:24:
|
||||||
|
|
||||||
|
```
|
||||||
|
mesh-controller built 2ebbb799 g14 2026-10-03 19:24
|
||||||
|
```
|
||||||
|
|
||||||
|
Twenty-seven minutes later the plan still read `tier 1 of 3 … mesh-controller asked`, and every later
|
||||||
|
plan waited behind it. It was stopped by hand; the later tiers were never asked.
|
||||||
|
|
||||||
|
## Why it matters beyond this instance
|
||||||
|
|
||||||
|
The controller rebuilding itself is the one plan whose first tier replaces the process that runs the
|
||||||
|
plan. The new controller starts with the plan's state as stored, and the outcome of the build that
|
||||||
|
produced it arrived to the old one, or between the two. Every merge to the controller's own repository
|
||||||
|
can end this way, and each one blocks every plan after it until somebody notices.
|
||||||
|
|
||||||
|
## Diagnosis
|
||||||
|
|
||||||
|
Owner mesh-controller (the planner). **Fix direction:** on start, and whenever a plan waits on a
|
||||||
|
build, the plan settles an `asked` build against the build records — a build recorded as built from
|
||||||
|
the plan's commit is that tier's outcome — so a plan resumes after the controller replaced itself.
|
||||||
|
A test: a plan whose build outcome was recorded while no controller followed it resumes on start.
|
||||||
@@ -0,0 +1,35 @@
|
|||||||
|
---
|
||||||
|
status: open
|
||||||
|
opened: 2026-10-03
|
||||||
|
located-in:
|
||||||
|
- mesh-controller
|
||||||
|
fixed-by:
|
||||||
|
amended-design:
|
||||||
|
---
|
||||||
|
|
||||||
|
# 215 — A module built once at a commit stops following its branch, and merges leave it out
|
||||||
|
|
||||||
|
## What was observed
|
||||||
|
|
||||||
|
2026-10-03, a catalogue merge changed seven modules. Its plan built six; `unifi` was not in it,
|
||||||
|
though its change was in the same commit. A second merge the same evening left it out again. Its
|
||||||
|
build records name a commit where every other module names a branch:
|
||||||
|
|
||||||
|
```
|
||||||
|
unifi built 9c97a8a1 … http://…/mesh-catalog.git at 9c97a8a
|
||||||
|
```
|
||||||
|
|
||||||
|
Built by hand from `main` it was registered again and the change reached its machine.
|
||||||
|
|
||||||
|
## Why it matters beyond this instance
|
||||||
|
|
||||||
|
A module that was once built at a commit — to pin it during a fix, or by a build asked with a `ref`
|
||||||
|
— silently stops following its branch: merges plan without it, `status` does not say it is behind its
|
||||||
|
branch, and nothing says it is pinned. The operator learns it when a change does not arrive.
|
||||||
|
|
||||||
|
## Diagnosis
|
||||||
|
|
||||||
|
Owner mesh-controller. **Fix direction:** a build asked at a commit does not change the branch a
|
||||||
|
module follows; or, if pinning is meant, the pin is said — in `module list`, in `status`, and by a
|
||||||
|
merge's plan naming the module it leaves out and why. A test: building a module at a commit and then
|
||||||
|
merging a change to it plans it.
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
status: open
|
||||||
|
opened: 2026-10-03
|
||||||
|
located-in:
|
||||||
|
- mesh-controller
|
||||||
|
fixed-by:
|
||||||
|
amended-design:
|
||||||
|
---
|
||||||
|
|
||||||
|
# 216 — A tools bundle nothing says to load is built, recorded, and never delivered
|
||||||
|
|
||||||
|
## What was observed
|
||||||
|
|
||||||
|
2026-10-03, seven modules moved their tools from a container to a bundle. Each built, each build was
|
||||||
|
recorded, and the machines that run them reported current — with none of the bundles on them. The
|
||||||
|
composer delivers a bundle only when the runtime loads something from it, and that is derived from
|
||||||
|
the module's `tools` list when the artifact names no `loads`; these modules had neither.
|
||||||
|
|
||||||
|
## Why it matters beyond this instance
|
||||||
|
|
||||||
|
Every step reported success: the build, the registration, the push, the machine's apply. The tools
|
||||||
|
were simply absent, and the old container was gone. A rule the composer applies silently is a rule
|
||||||
|
nobody learns until the tools are missing.
|
||||||
|
|
||||||
|
## Diagnosis
|
||||||
|
|
||||||
|
Owner mesh-controller (the catalogue's registration check). **Fix direction:** a bundle that nothing
|
||||||
|
loads, runs or unpacks — no `loads`, no `tools` list on its module, no resource naming it — is refused
|
||||||
|
at registration, naming the field that would deliver it. A test: such a manifest is refused; adding
|
||||||
|
`loads` admits it.
|
||||||
Reference in New Issue
Block a user