Files
felhom.eu/documentation/audits/update-night-2026-09-21/26-removed-app-came-back.txt
T
admin 8d786f7940
gates / gates (push) Successful in 28s
Update night 2026-09-21: the full record, twelve rows, and the answers to five of the seven questions
The drill is complete. Teardown done in three layers plus Gitea; the live catalog's every `image:`
line is proven identical to before.

WHAT WAS MEASURED. 21 edges across 19 apps, on scratch guest 9202 through the product's own
guarded Update, against a PRIVATE DRILL CATALOG so the live catalog carried no test reference at
any point: 14 proven, 3 failed, 4 inconclusive. Each app seeded and read back through its OWN
front door, with a negative control on every readback. Ten of the fourteen printed a verbatim
migration line. Up from the three apps this project had ever measured.

THE RESULT THAT MATTERS. R-618, P1: three of the 53 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. tandoor was measured serving HTTP 200 on the new version at four samples
across five minutes, docker's own healthcheck green, and was then stopped and the household sent
to a restore they did not need. zipline and wger are the same defect, both confirmed live. The
gate that catches all three is static and cheap: both health checks already sit in the same file.

WHAT THE NIGHT ANSWERED that was open. The UNATTENDED HOLD (312.9 s, pressed once, never again) —
which needed a purpose-built image store, because the rule that makes automatic updates safe is
the same rule that refuses the obvious way to break one. MariaDB across a major through the real
button, all four observables, first time. PostgreSQL across a major, refusing exactly as predicted,
with the conversion costed at ~9 s of engine work. There is NO single-flight: five updates ran at
once and all ended honest. And the two EARLY power-cut phases nobody had cut in.

TWELVE NEW ROWS (R-615..R-626), register 303 -> 315, and eight existing rows updated with what was
measured — including two CORRECTIONS: R-606 records the pre-flight refusals as reaching an English
household in English and they do not, and R-446/R-458 are both narrower than their rows state.

Two instrument fixes were needed before anything could be trusted: the unattended caller turned
every success into a timeout (R-623), and one of my own reproductions was wrong and is kept
labelled with what it actually measured.

Interventions: zero. No controller, agent or hub code written. The hub was never touched beyond
the floor the operator asked for.

Gates: repo_gates.py --fast, all 15 OK.

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

29 lines
1.8 KiB
Plaintext

=== navidrome AFTER a removal that returned 200
created=2026-09-21T19:12:20.845623139Z started=2026-09-21T20:19:33.374056273Z restart=unless-stopped image=deluan/navidrome:0.64.0
compose project label: navidrome
app.yaml: ls: cannot access '/opt/docker/stacks/navidrome/app.yaml': No such file or directory
volume: 1 navidrome volume(s) left
TIMELINE, from the container's own metadata
-------------------------------------------
21:12:05 local POST /api/stacks/navidrome/remove {remove_hdd_data:true} -> 409 (drive path
unresolvable, R-442's fail-closed guard — correct)
21:12:11 local POST /api/stacks/navidrome/remove {remove_hdd_data:false} -> 200,
volumes_removed = ['navidrome_navidrome_data']
21:12:18 local the harness's own leftovers check reported deployed=False and no containers
21:12:20 local A NAVIDROME CONTAINER WAS CREATED (= container .Created, 19:12:20Z)
22:19:33 local ...and STARTED again by Docker's `restart: unless-stopped` at the B5 power cut
22:27:20 local the teardown found it: deployed=False, state=running
WHAT IS AND IS NOT ESTABLISHED
------------------------------
ESTABLISHED: the app's RECORD is gone (`app.yaml` absent, `deployed=false`), its VOLUME is gone,
and a container carrying `com.docker.compose.project=navidrome` was created two seconds after the
removal returned 200 and has run ever since. The controller probes it and calls it healthy
(`Health probe navidrome: API GET :4533/ping -> 200`).
NOT ESTABLISHED: WHAT created it. The controller was restarted several times later in the night
(knob changes and two power cuts) and its log no longer reaches 19:12:20Z. This is stated as an
observation, not a diagnosis — and it is the second time tonight that a restart destroyed the
evidence of the thing that mattered (see R-621).