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

hub v0.73.0 — offsite_stale anchored on newborn tiers (never-ran = applied-only + consumed_at/escrow anchor; one state one owner)

Browse Source 
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NKSN3gSg4TKVBBqkwW2djR
This commit is contained in:
authentik Default Admin
2026-07-23 13:25:22 +02:00
parent 527d81cf70
commit b03a53ddcf
4 changed files with 297 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
hub/CHANGELOG.md
+32 -1
View File
@@ -1,6 +1,37 @@
# Felhom Hub — Changelog
## v0.72.0 — R-70 + R-71(c): the offsite last mile becomes visible, and burned credentials heal themselves (2026-07-23)
## v0.73.0 — `offsite_stale` no longer cries wolf on a newborn tier (ISO-train v1.25.0 Part 7) (2026-07-23)
Origin (operator, 2026-07-23 12:01 CEST): demo-hp's offsite was repaired and escrowed at 10:01Z and
`offsite_stale` fired MINUTES later (`last_run:"" … threshold 48h0m0s`) — the never-ran branch had
no time anchor, so "enabled + escrowed + never ran" was instantly stale on the first tick, with
remedy copy ("check the controller/schedule") that was wrong for the moment's true state.
**The fix (no new constant, one boundary) — `monitor.OffsiteChecker.isStale`:**
- **Boundary ruling (recorded):** never-ran staleness is owned by `offsite_stale` ONLY in the
v0.72.0 `applied` delivery state; pre-applied never-ran shapes belong to
`offsite_delivery_stuck` alone — **one state, one owner, never both**. Structurally this was
already true (`Check` nil-skips reports without the offsite object, and a report CARRYING the
object IS `applied` by the v0.72.0 definition) — now it is pinned by an explicit boundary test
that also asserts the delivery checker remains that shape's only voice.
- **Anchor:** never-ran staleness = `applied` AND (now − anchor) > the EXISTING 48 h threshold,
where anchor = the newest of **`one_time_secrets.consumed_at`** (delivery completed; via the
v0.72.0 `GetOneTimeSecretInfo`) and the customer's **escrow-blob timestamp**
(`host_escrow.updated_at`/`created_at` via the new `LatestEscrowTimeForCustomer` — reduced in
Go, not SQL MAX, because the two timestamp formats would misorder lexicographically). Runs
become possible only at the ceremony, so the ceremony anchors the clock. No separate grace
knob: the existing threshold, anchored properly, IS the grace.
- Anchor-less legacy shape (no secret row, no escrow row): pre-fix behavior kept — stale on
sight, fail toward visibility. Ran-before behavior byte-untouched (explicit both-direction
tests: old run + fresh anchor still fires; fresh run + old anchor stays silent).
- One INFO log line on the FIRST observation of a deferred newborn (`never-ran within the
anchored threshold (anchor …)`) — the anchored evaluation is provable live without per-sweep
spam.
Red-proof: never-ran branch reverted to the pre-fix `return true` → the fresh-anchor fixture and
the escrow-anchor fixture both fired `offsite_stale:warning` (FAIL observed) → fix restored.
Origin: `documentation/audits/DIAG-f10-demo-hp-offsite-2026-07-23.md` — demo-hp sat 2 days with the
customer card claiming "Provisioned … delivered to the controller once" (static copy) while the box