v0.184.0 — E-2b + Part 5: wire the drive-absent alarm that was never called

NotifyStorageDisconnected and NotifyStorageReconnected were defined and called
from NOWHERE. Registered in allowedEventTypes, in DefaultEnabledEvents, and given
a Hungarian message on the hub -- and never invoked. A drive going absent produced
apps stopped, a WARN log and a UI badge, then silence on every channel. Verified
against the gitignored-cmd/ trap with a positive control. Fifth instance of this
class, found by E-2 Phase 0 rather than by a failure.

A drive that is ONLY a backup target has no apps to stop, so it was silent twice.

ReconcileDriveGates now calls both halves. When the absent drive is the whole-guest
backup target it raises the more specific backup_target_absent (error) instead --
never both, since two mails for one event trains people to ignore the channel --
and recovers as backup_target_restored (info, the existing pairing-gated pattern;
severityNotifies NOT widened). The recovery mirrors the alarm's choice or the
operator cannot match them.

Which drive is the target comes from the AGENT (/disks backup_target, >= 0.112.0),
not from our StoragePath.BackupTarget: that is customer INTENT, and on the two
boxes migrated by hand in E-1 the intent was never recorded while the drive really
is the target. An older agent omits the field -> false -> generic alarm, never a
wrong one.

Before this an absent backup target had NO prompt signal: the tier stays DUE
(targetStoragePresent checks name presence, never reachability), so the only
evidence was its own failure at the next due cycle, up to ~24h away. The R-100
shape.

Tests observe the WIRE, not a mock, because the failure class is "nothing
arrives": a real Notifier posts to an httptest hub and the test asserts the event
type and severity that actually went out.

MinAgent: 0.112.0
Green gate: build + vet + test rc=0 (27 packages), run separately from this commit.
This commit is contained in:
2026-07-29 08:21:25 +02:00
parent ff058a4f10
commit c1a63de1c7
5 changed files with 228 additions and 0 deletions
+30
View File
@@ -1,5 +1,35 @@
## Changelog
### v0.184.0 — E-2b + Part 5: the drive-absent alarm that was never wired (2026-07-29) — MinAgent 0.112.0
**`NotifyStorageDisconnected` and `NotifyStorageReconnected` were defined and called from NOWHERE.**
Registered in `allowedEventTypes`, in `DefaultEnabledEvents`, and given a Hungarian message on the
hub — and never invoked. A drive going absent produced apps stopped, a `[WARN]` log and a UI badge,
then **silence on every channel**. Verified against the gitignored-`cmd/` trap with a positive
control. Fifth instance of this class in the project, found by E-2's Phase 0 rather than by a
failure.
A drive that is *only* a backup target has no apps to stop, so it was silent twice over.
`ReconcileDriveGates` now calls both halves. When the absent drive is the **whole-guest backup
target** it raises the more specific `backup_target_absent` (error) instead — never both; two mails
for one event trains people to ignore the channel — and recovers as `backup_target_restored` (info,
the existing pairing-gated pattern; `severityNotifies` is NOT widened). The recovery must mirror the
alarm's choice or the operator cannot match them.
**Which drive is the target comes from the AGENT** (`/disks` `backup_target`, agent ≥ 0.112.0), not
from our own `StoragePath.BackupTarget`: that field is customer INTENT, and on the two boxes migrated
by hand in E-1 the intent was never recorded while the drive really is the target. An older agent
omits the field → false → the generic disconnect alarm, never a wrong one.
Before this, an absent backup target had **no prompt signal at all**: the tier stays DUE
(`targetStoragePresent` checks name presence, never reachability), so the only evidence was the
tier's own failure at its next due cycle — up to ~24 h on the daily local tier. The R-100 shape.
**Tests** observe the WIRE, not a mock, because the failure class is "nothing arrives": a real
`Notifier` posts to an `httptest` hub and the test asserts the event type and severity that actually
went out. A typo in the type string is not cosmetic — the hub 400s it and the event vanishes.
### UNRELEASED — E-2 Part 1: the backup-target role (foundation; NOT yet wired to a UI)
**Status: foundation only. No version bump — nothing customer-visible changes yet.** The field is