1.5 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |
|---|---|---|---|---|---|
| open | 2026-10-03 |
|
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.