42 lines
1.8 KiB
Markdown
42 lines
1.8 KiB
Markdown
---
|
|
status: resolved
|
|
opened: 2026-10-03
|
|
located-in:
|
|
- mesh-controller
|
|
fixed-by:
|
|
- mesh-controller#246
|
|
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.
|
|
|
|
## Resolved
|
|
|
|
A plan settles an asked build from the build records, whoever heard the outcome. Proven 2026-10-03 and 2026-10-04: both controller merge plans since the fix finished all three rounds, including the round that replaced the controller, without being stopped by hand.
|