admin/felhom-controller
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.191.1 — the fill check also runs at startup (R-167)
gates / gates (push) Successful in 9s
Details

Browse Source 
Found live on 9201: neither sched.Daily nor sched.Every fires on
registration, so a box booting with a filesystem already over the line
would stay silent for up to 24h — the R-100 shape, and the same gap the
hub's own checkers avoid by leaving already-breached keys unseeded at init.

The watcher now runs once 90s after startup as well. Safe because the check
is edge-triggered against persisted state: an already-warned filesystem
stays silent. The delay lets mounts settle so a drive still returning reads
as unreadable and is skipped rather than warned about. Pinned by an AST
assertion — the schedule registration alone no longer satisfies the test.
This commit is contained in:
authentik Default Admin
2026-08-02 23:27:35 +02:00
parent cf48214f6c
commit 5adae4dad9
3 changed files with 89 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+20
View File
@@ -1,5 +1,25 @@
## Changelog
### v0.191.1 — the fill check also runs at startup (2026-08-02, R-167) — MinAgent: none
**Found while live-validating v0.191.0 on guest 9201: the fill check was reachable only on its daily
schedule, and neither `sched.Daily` nor `sched.Every` fires on registration — both wait for their
first tick.** So a box that BOOTS with a filesystem already over the line would have stayed silent for
up to 24 hours. That is the R-100 shape — a real fault visible only after a deadline elapses — and the
hub's own checkers handle exactly this case deliberately, leaving already-breached keys unseeded at
init so their first `Check` emits (the F2 lesson, `monitor/storage_fill.go`). A daily-only schedule
here would have been the same gap one component over.
The watcher now also runs **once, 90 s after startup**. The delay lets mounts settle and the drive
gate tick first, so a drive still coming back reads as unreadable and is skipped (§8.4) rather than
warned about. It is safe to add because the check is edge-triggered against PERSISTED state: a
filesystem the customer has already been warned about stays silent, so this adds a warning only where
one is genuinely owed. Pinned by an AST assertion in `TestMainWiresTheFillWatcher` — the schedule
registration alone no longer satisfies it.
**Disclosure:** this also made the flow live-validatable at all. There is still no operator-triggerable
"run the fill check now" path; that is recorded as an observation, not fixed here.
### v0.191.0 — warn before the wall comes down (2026-08-02, R-167 · R-158 · R-174) — MinAgent: none
**Storage monitoring and backup alerts, decision D-c, landing BEFORE the `mp1`→`mp0` merge (D-a /