Files
felhom.eu/documentation/audits/update-night-2026-09-21/21-B9-frozen-app-newer-felhomyml.md
T
admin 9c69b3ff07
gates / gates (push) Successful in 27s
Update night: Phases 2-4 evidence — both engines, the unattended HOLD, and five new findings
Evidence off the machine at the end of the phases that produced it (R-320). Teardown follows.

PHASE 2 — the two database engines, through the REAL Update button:
- MariaDB 11.6 -> 12.3 on nextcloud: PROVEN, and pressed through the button for the first time.
  All four SPIKE-r459 observables: the datadir's own record moved 11.6.2 -> 12.3.3; the engine
  itself says "already upgraded ... no need to run mariadb-upgrade again"; the entrypoint says
  "Major version upgrade detected ... Check required!" and then STARTED and FINISHED it (not the
  `skipped due to $MARIADB_AUTO_UPGRADE` line R-459 feared); and the engine took its own
  pre-upgrade backup, 631 905 B. The seeded Nextcloud account read back.
- PostgreSQL 16 -> 17 on docmost: FAILED exactly as R-463 predicted and nobody had measured.
  5.1 s to held; the pin named 17 while nothing ran; the restore brought it back in 29.1 s.
  The engine's REFUSAL LINE was destroyed by failAndHold before any probe could read it, so it
  was REPRODUCED INDEPENDENTLY with a control on every step (R-320).

PHASE 3 — the bad days. B1 produced THE UNATTENDED HOLD, which this project has never had: the
caller pressed once with nobody watching, the app held after 312.9 s, and passes 2 and 3 pressed
nothing. B2 put the pin back on a pull failure in 1.0 s. B3 refused `busy` six times. B4 showed
there is NO single-flight — 5 of 5 updates ran at once and all ended honest. B5 cut the power in
`backing-up` and the box recovered itself and said so. B7 refused under the 2 GB floor. B9 found
R-458's risk narrower than the row states.

PHASE 4 — every badge on the box is TRUE, and the held app answers all four of Q4's questions.

FINDINGS, five new and three corrections to existing rows. The one that matters: R-618 is P1 —
two templates name a health probe the app does not answer, and because the guarded update waits
on that same probe, a SUCCESSFUL update ends by STOPPING a working app. Measured: tandoor served
HTTP 200 on the new version at four samples across five minutes and was then stopped.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
2026-09-21 22:13:57 +02:00

2.2 KiB

B9 — a FROZEN app receives a newer .felhom.yml (R-458). MEASURED, and it REFINES the row.

Setup. bentopdf frozen: installed ghcr.io/alam00000/bentopdf:v2.8.6, catalog localhost:5000/drill/pdf:1.0.1. A .felhom.yml-ONLY change was pushed to the drill catalog — a health check for a path only a newer version would serve, /__drill_only_in_the_newer_version__. No image: line was touched.

§5.4's deliberate asymmetry, confirmed live

On the box, after one sync:

.felhom.yml   checks: - type: http, port: 8080, path: /__drill_only_in_the_newer_version__
                      - type: http, port: 8080                      <- the original
compose       image: ghcr.io/alam00000/bentopdf:v2.8.6              <- UNCHANGED

So the .felhom.yml kept flowing to a frozen app while the compose file stayed frozen, exactly as 09 §5.4 says and for the reason it gives (the file carries catalog_since, which the badge needs).

R-458's claim holds — and the reason is NARROWER than the row states

Ten samples over two minutes, every one:

state = running     front door = HTTP 200

No false alarm was produced at all, and the reason is the probe's own semantics rather than luck. healthprobe.go:258-261: for type: http, any response is healthy. The bogus path answers 404 — which is a response. So a health check written for a newer version cannot make a type: http app read degraded, however wrong the path is.

The refinement R-458 should carry: its false-alarm risk is real only for type: api probes that carry an expect block, where the status is compared. Of the 53 templates, that is the minority — and it is the same subset R-618 convicts zipline in. For every type: http template and every type: api WITHOUT expect, a path that a newer version would serve is simply invisible to the probe.

And the direction is confirmed, which is the row's actual claim: the failure direction is a false alarm, never data loss. Nothing touched the app's data; the app never stopped; the card showed the previous pull failure's sentence („Az új verzió letöltése nem sikerült, ezért a frissítés elmaradt.") and nothing new.

Teardown: the .felhom.yml was reverted in the drill catalog in the same leg.