Say a module's health is not yet judged while it changes, and judge it as soon as its change ends (issue 1945) #141

2026-10-25T14:53:36Z

mesh-tools commented

2026-10-25 14:53:36 +00:00

Issue 1945 (R6 recovery, fix 15).

Two faults of one kind: a have reported a health nothing had judged.

xorg stayed unknown (1cdb4d1): a packages-only module kept the health "unknown" an older engine left, so every module requiring x11-display waited on it. At the agent's start, a module found running on its own have is written again, so its health is this engine's; a module with no resources is ok after a look.
The controller's canary was held on novox at 15:27:36 (c16e625): a look that caught the old container mid-replacement made the have say "applying, failed", and the assigner held mesh-controller #462's build two seconds before it was healthy. While a module is backing-up, applying or checking its health is unknown; a look in that time judges nothing; when an apply begins or the fingerprint or digest changes, the last health is dropped until a look after the move.
No five-minute wait after an apply (b32a27c, review round 1): when a module leaves motion unjudged, the health loop is nudged (link.Session.HealthOwed) and judges it at once; no timer changed. A declaration report gets the same motion check; removals drop their unjudged marks.

Tests: TestAHealthIsNotJudgedWhileAModuleIsApplied, TestAHealthIsNotCarriedOverToAnotherComposition (fail on the live rows without the fix), TestAModuleWithNothingLongRunningIsOkWithinALookOfItsApply, TestADeclarationReportMovesAHealthAndARemovalForgetsIt.

Checked: gofmt, go vet with and without -tags integration, the unit suite, go test -race on ./internal/link and ./cmd/mesh-host. Tries passed on 1cdb4d1 (try-1792938492144780407) and c16e625 (try-1792938805775984133); none on b32a27c, because the operator decided no checks run during the recovery (2026-10-25 15:53, issue 1945 note 27): the operator merges by hand.

The assigner's half (a failed health counts only in phase running or failed) is in mesh-delivery fix/r6-no-module-in-neither.

Reviewed-by: reviewer-r6q@shanks at b32a27c115

Issue 1945 (R6 recovery, fix 15). Two faults of one kind: a have reported a health nothing had judged. - **xorg stayed unknown** (1cdb4d1): a packages-only module kept the health "unknown" an older engine left, so every module requiring x11-display waited on it. At the agent's start, a module found running on its own have is written again, so its health is this engine's; a module with no resources is ok after a look. - **The controller's canary was held on novox at 15:27:36** (c16e625): a look that caught the old container mid-replacement made the have say "applying, failed", and the assigner held mesh-controller #462's build two seconds before it was healthy. While a module is backing-up, applying or checking its health is unknown; a look in that time judges nothing; when an apply begins or the fingerprint or digest changes, the last health is dropped until a look after the move. - **No five-minute wait after an apply** (b32a27c, review round 1): when a module leaves motion unjudged, the health loop is nudged (link.Session.HealthOwed) and judges it at once; no timer changed. A declaration report gets the same motion check; removals drop their unjudged marks. Tests: TestAHealthIsNotJudgedWhileAModuleIsApplied, TestAHealthIsNotCarriedOverToAnotherComposition (fail on the live rows without the fix), TestAModuleWithNothingLongRunningIsOkWithinALookOfItsApply, TestADeclarationReportMovesAHealthAndARemovalForgetsIt. Checked: gofmt, go vet with and without -tags integration, the unit suite, go test -race on ./internal/link and ./cmd/mesh-host. Tries passed on 1cdb4d1 (try-1792938492144780407) and c16e625 (try-1792938805775984133); none on b32a27c, because the operator decided no checks run during the recovery (2026-10-25 15:53, issue 1945 note 27): the operator merges by hand. The assigner's half (a failed health counts only in phase running or failed) is in mesh-delivery fix/r6-no-module-in-neither. Reviewed-by: reviewer-r6q@shanks at b32a27c115a2499e339e049e0f120f882c9b3dd9

mesh-tools added 3 commits 2026-10-25 14:53:36 +00:00

Say a module found running on its own have again at the agent's start, so its health is this engine's and not an older engine's unknown 1cdb4d1a29

xorg's have on g14 and shanks kept the unknown an engine before 958ccbd wrote: the
baseline believed the have and never handed the module to the session, so no look
rewrote its health, and the assigner held every module requiring x11-display back.

Say a module's health is not yet judged while its change is under way and until a look after it c16e625a08

A have said applying and failed for the controller on novox at 15:27:36, from a look at the
container being replaced, two seconds before its launch said healthy; the assigner held the
canary on it and set novox back. A look now judges only a module that is not in motion, and a
module whose composition moved carries unknown until a look after the move.

Owe a look when a module's change ends unjudged, so a module with nothing long-running is ok within a look of its apply

mesh/delivery merged: source.main moved to novox/mesh-host@5f16cf507a0f

Details

mesh/check pass b32a27c115a2 on 0dfbe1a179f2 | unit 292 run, 1060 kept, 5 skipped | integration 295 run, 1062 kept, 4 skipped | over bound: unit (slow…

b32a27c115

The facts look inside an apply runs while the module is still applying and judges nothing; the
running write then left xorg running and unknown until the five-minute statement, holding every
x11-display consumer behind it. The running write now nudges the health loop, which looks and says
at once. A declaration's report gets the same motion and composition check, and a removed module
leaves nothing marked unjudged (review of fix 15).

mesh-tools commented

2026-10-25 14:53:40 +00:00

Delivery novox/mesh-host@b32a27c115a2 — merged since 2026-10-25T15:04:55Z

Source — source.main moved to novox/mesh-host@5f16cf507a. Whether it reached the machines is mesh-delivery-view's, derived from source.main, the wants and the haves.

Transitions

2026-10-25 14:53 (new) → proposed (announced): novox/mesh-host#141's head announced
2026-10-25 14:57 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail
2026-10-25 15:04 ready → merged (merged): on the trunk its modules follow: merged there

The commit's note under refs/notes/mesh-plan keeps every transition of this change up to its merge: git log --notes=mesh-plan.

**Delivery** `novox/mesh-host@b32a27c115a2` — **merged** since 2026-10-25T15:04:55Z **Source** — source.main moved to novox/mesh-host@5f16cf507a0f. Whether it reached the machines is `mesh-delivery-view`'s, derived from `source.main`, the wants and the haves. **Transitions** - 2026-10-25 14:53 (new) → proposed (announced): novox/mesh-host#141's head announced - 2026-10-25 14:57 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail - 2026-10-25 15:04 ready → merged (merged): on the trunk its modules follow: merged there The commit's note under `refs/notes/mesh-plan` keeps every transition of this change up to its merge: `git log --notes=mesh-plan`.

mesh-tools merged commit 5f16cf507a into main

2026-10-25 15:04:54 +00:00

mesh-tools deleted branch fix/r6-health-unknown

2026-10-25 15:04:55 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-host#141