A scheduled step may hold its module's own containers still (hq ADR 0189, issue 108) #77

2026-10-02T19:49:25Z

mesh-admin commented

2026-10-02 19:49:25 +00:00

Merge FIRST of all of group 8. The store's module declares while-stopped (mesh-catalog #229); a host that does not know the field refuses the whole declaration and would take the store down with it.

Rebased onto today's main — no conflicts, nothing the bundles refactor touched.

while-stopped on a scheduled container names resource ids of the same module's containers. The host stops each before the run and starts each again after it, in the reverse order.

The restart is deferred before the first stop and runs on a context of its own, not the run's: a panic, a failing step, a host shutting down mid-window — each ends with the service running. The one real risk of this field is a window that never closes, and the only defence against it is that closing is not conditional on anything. A container that will not come back is said in the loudest line this host writes.

Refused on arrival: a window with no schedule (at apply the declaration is applied in order and a run-once step already gates what follows, so a one-time offline job says before), one naming itself, one naming an id that is not a container in this declaration.

internal/apply/maintenance_window_test.go: stop–run–start in order; the restart after a step that failed; the reverse order for two containers; the loud line; and the three refusals, each for what it says. Run against the unchanged host first — it refuses the fixture, which is the right way for it to fail.

go test ./..., go vet, gofmt all clean on today's main.

**Merge FIRST of all of group 8.** The store's module declares `while-stopped` (mesh-catalog #229); a host that does not know the field refuses the whole declaration and would take the store down with it. Rebased onto today's main — no conflicts, nothing the bundles refactor touched. `while-stopped` on a scheduled container names resource ids of the same module's containers. The host stops each before the run and starts each again after it, in the reverse order. The restart is **deferred before the first stop** and runs on a context of its own, not the run's: a panic, a failing step, a host shutting down mid-window — each ends with the service running. The one real risk of this field is a window that never closes, and the only defence against it is that closing is not conditional on anything. A container that will not come back is said in the loudest line this host writes. Refused on arrival: a window with no schedule (at apply the declaration is applied in order and a run-once step already gates what follows, so a one-time offline job says *before*), one naming itself, one naming an id that is not a container in this declaration. `internal/apply/maintenance_window_test.go`: stop–run–start in order; the restart after a step that **failed**; the reverse order for two containers; the loud line; and the three refusals, each for what it says. Run against the unchanged host first — it refuses the fixture, which is the right way for it to fail. `go test ./...`, `go vet`, `gofmt` all clean on today's main.

jschoubben added 1 commit 2026-10-04 00:45:53 +00:00

A scheduled step may hold its module's own containers still (hq ADR 0189) e8c4824ae2

while-stopped names resource ids of the same module's containers; the host
stops them before the run and starts them again after it, in reverse order,
whatever the step did. The restart is deferred before the first stop and runs
on its own context, because the one real risk of this field is a window that
never closes.

Scheduled steps only: at apply the declaration is applied in order and a
run-once step already gates what follows.

jschoubben force-pushed feat/the-store-keeps-what-the-records-name from f3e135dfc9 to e8c4824ae2

2026-10-04 00:45:53 +00:00

Compare

jschoubben added 1 commit 2026-10-04 01:27:42 +00:00

A changed maintenance window is a changed spec (hq ADR 0189) b602b223e1

containerSpec says a changed cadence moves the marker so the install is
reported updated and re-established. Which containers are held still is the
same kind of statement, and a declaration that changed it while the machine
reported no change would be a machine quietly holding yesterday's containers.

mesh-admin commented

2026-10-04 01:31:25 +00:00

HELD — do not merge yet. hq #305 is merged (ADR 0189 is on main). This one waits.

Why. main here is 4 commits ahead of what is deployed (99ad145), and the gap is issue 223's genesis pivot — raising a process-form controller as the container it replaces. A merge rebuilds the host and rolls it to every machine, so merging this would carry that out under this change's name.

This is still first in group 8's order once the 213/223 cutover has rolled: mesh-host (this) → mesh-controller #227 → mesh-sdk #10 → mesh-catalog #229. A host that does not know while-stopped refuses the store's whole declaration.

One defect found in the pre-merge review and fixed here (commit b602b22): a changed while-stopped did not move the container's spec. containerSpec already says a changed cadence moves the marker so the install is reported updated and re-established; which containers are held still is the same kind of statement, and without it a declaration that changed the window would have reported no change while the machine went on holding yesterday's containers. Test fails against the unfixed code.

One gap recorded rather than fixed: hq issue 224 — an apply arriving during an open window recreates the container the window is holding, because applyContainer reads a stopped container as one to replace, and while-stopped is the first thing in the mesh that makes a stopped container intentional. The two candidate fixes (the window takes the apply lock; or the apply learns which containers are held) are each a decision with its own cost.

**HELD — do not merge yet.** hq #305 is merged (ADR 0189 is on main). This one waits. **Why.** `main` here is **4 commits ahead of what is deployed** (`99ad145`), and the gap is issue 223's genesis pivot — raising a process-form controller as the container it replaces. A merge rebuilds the host and rolls it to every machine, so merging this would carry that out under this change's name. This is still **first** in group 8's order once the 213/223 cutover has rolled: mesh-host (this) → mesh-controller #227 → mesh-sdk #10 → mesh-catalog #229. A host that does not know `while-stopped` refuses the store's whole declaration. **One defect found in the pre-merge review and fixed here** (commit `b602b22`): a changed `while-stopped` did not move the container's spec. `containerSpec` already says a changed *cadence* moves the marker so the install is reported updated and re-established; which containers are held still is the same kind of statement, and without it a declaration that changed the window would have reported no change while the machine went on holding yesterday's containers. Test fails against the unfixed code. **One gap recorded rather than fixed:** hq issue 224 — an apply arriving during an open window recreates the container the window is holding, because `applyContainer` reads a stopped container as one to replace, and `while-stopped` is the first thing in the mesh that makes a stopped container intentional. The two candidate fixes (the window takes the apply lock; or the apply learns which containers are held) are each a decision with its own cost.

mesh-admin merged commit 27fb22fddb into main

2026-10-04 01:39:07 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-host#77