An apply leaves a container a maintenance window holds still (hq issue 224) #23

2026-10-05T16:27:52Z

mesh-admin commented

2026-10-05 16:27:52 +00:00

A while-stopped step stops its module's containers; an apply arriving mid-window found the container stopped and recreated it running — for the registry's nightly collection, a window in which a build's upload can be swept (hq issue 224, ADR 0189). Chosen of the issue's two options: the apply learns what a window holds (nothing blocks; pushes are not held for minutes).

The scheduler records each window (step, containers, opened, expires after 6 h, the process that opened it) under the host's state dir — the one place the daemon, a hand-run apply and the installer share — written before the first stop, erased in a defer after the containers start again; a window whose record cannot be written does not run. A window past its expiry or whose process is gone holds nothing.
applyContainer reports a held container held-still, naming the step, and leaves it — converged by the first apply after the window (said when its declaration moved). Not a change, triggers no restart-on.
The machine's report lists open windows (windows), so a half-stopped machine at 03:31 reads as working.

Tests: an apply mid-window leaves the held container alone and converges it after; a failed step releases its hold; an expired or orphaned window holds nothing; an unrecordable window is not opened. go test -race ./... all packages ok; vet, gofmt clean. Known and accepted: a sub-second race between an apply's inspect and its rm if a window opens exactly then.

A `while-stopped` step stops its module's containers; an apply arriving mid-window found the container stopped and recreated it running — for the registry's nightly collection, a window in which a build's upload can be swept (hq issue 224, ADR 0189). Chosen of the issue's two options: the apply learns what a window holds (nothing blocks; pushes are not held for minutes). - The scheduler records each window (step, containers, opened, expires after 6 h, the process that opened it) under the host's state dir — the one place the daemon, a hand-run apply and the installer share — written before the first stop, erased in a defer after the containers start again; a window whose record cannot be written does not run. A window past its expiry or whose process is gone holds nothing. - `applyContainer` reports a held container `held-still`, naming the step, and leaves it — converged by the first apply after the window (said when its declaration moved). Not a change, triggers no restart-on. - The machine's report lists open windows (`windows`), so a half-stopped machine at 03:31 reads as working. Tests: an apply mid-window leaves the held container alone and converges it after; a failed step releases its hold; an expired or orphaned window holds nothing; an unrecordable window is not opened. `go test -race ./...` all packages ok; vet, gofmt clean. Known and accepted: a sub-second race between an apply's inspect and its rm if a window opens exactly then.

mesh-admin added 1 commit 2026-10-05 16:27:52 +00:00

An apply leaves a container a maintenance window holds still (hq issue 224) f08681f225

A while-stopped step stops its module's containers, and an apply arriving
mid-window read the stopped server as broken and recreated it running under
the step - for the store's collector, a registry taking an upload the sweep
then deletes. The scheduler now records each window under the node's state
directory before its first stop and erases it after its last start, so every
apply on the machine (daemon, reconcile by hand, installer) reports a held
container held-still and leaves it for the first apply after the window.
A window whose host died, or past six hours, holds nothing; the report says
which windows are open.

mesh-admin merged commit 7063b183af into main

2026-10-05 16:27:56 +00:00

mesh-admin deleted branch fix/an-apply-leaves-a-held-container-held

2026-10-05 16:27:56 +00:00

mesh-admin commented

2026-10-06 23:10:41 +00:00

Delivery novox/mesh-host@7063b183aff9 — held since 2026-10-06T23:05:28Z

Held for a person: merged without a passing check: only a person decides that it goes on — mesh-delivery.release with why lets it go on.

Delivery plan — builds mesh-host → ace, g14, novox, shanks; no bus step

tier 0: mesh-host
ace: receives mesh-host
g14: receives mesh-host
novox: receives mesh-host
shanks: receives mesh-host

Transitions

2026-10-06 23:05 (new) → proposed (announced): novox/mesh-host#23 merged; its head was not heard by this owner, so it is made from the forge's word
2026-10-06 23:05 proposed → held (merged-unchecked): merged without a passing check — a verdict known with it is taken first: only a person decides that it goes on

The commit's note under refs/notes/mesh-plan keeps every transition: git log --notes=mesh-plan.

**Delivery** `novox/mesh-host@7063b183aff9` — **held** since 2026-10-06T23:05:28Z Held for a person: merged without a passing check: only a person decides that it goes on — `mesh-delivery.release` with why lets it go on. **Delivery plan** — builds mesh-host → ace, g14, novox, shanks; no bus step - tier 0: mesh-host - ace: receives mesh-host - g14: receives mesh-host - novox: receives mesh-host - shanks: receives mesh-host **Transitions** - 2026-10-06 23:05 (new) → proposed (announced): novox/mesh-host#23 merged; its head was not heard by this owner, so it is made from the forge's word - 2026-10-06 23:05 proposed → held (merged-unchecked): merged without a passing check — a verdict known with it is taken first: only a person decides that it goes on The commit's note under `refs/notes/mesh-plan` keeps every transition: `git log --notes=mesh-plan`.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-host#23