snapshot.sh backs up one hardcoded database and still reports ok #108

New issue

Closed

opened 2026-09-23 10:46:22 +01:00 by cruelacid · 1 comment

cruelacid commented

2026-09-23 10:46:22 +01:00

Owner

Why

deploy/ops/snapshot.sh backs up exactly one database, by name, and says
snapshot ok regardless of what else is on the box.

Line 107:

pg() { docker compose exec -T glitchtip-postgres sh -c "$1"; }

Add any stateful service to the ops box and the snapshot still succeeds while
containing nothing of it. deploy/UPGRADES.md makes that exit code the gate for
every ops upgrade — "no copy, no upgrade" — so the gate would be passing on a
copy that is missing the thing being upgraded.

This surfaced while designing a feedback board for the ops box. It is worth
fixing regardless of whether that board is ever built, which is why it is filed
on its own rather than inside it.

Today the box happens to have one stateful service, so nothing is lost right now.
The failure is that adding the second is silent.

What to do

A completeness assertion. The script already enumerates services for the
manifest at line 87:

for svc in $(docker compose config --services); do

Have it also fail when a declared service is in neither a BACKED_UP nor a
STATELESS list. Adding a service then forces a deliberate choice instead of a
silent omission.

Then cross-check the lists from a test — the idiom this repository already uses
twice. inventory.mjs keeps HOST_FILES identical to install-deployer.sh's
CHECKED_FILES with a test that reads the file, for the stated reason that two
checkers disagreeing about what healthy means is how the ops box stayed
unswept; console.test.ts does the same for UPGRADEABLE against parsePins.

deploy/test/snapshot.test.ts: read snapshot.sh and deploy/ops/docker-compose.yml,
assert every declared service is accounted for in one list or the other.

Verification

Mutation-check it, in both directions. Feed a compose fixture containing an
unlisted service and confirm the test fails; then confirm it passes on the
real file. A test that has never failed proves nothing, and that is the whole
point of this issue.

## Why `deploy/ops/snapshot.sh` backs up exactly one database, by name, and **says `snapshot ok` regardless of what else is on the box.** Line 107: ```sh pg() { docker compose exec -T glitchtip-postgres sh -c "$1"; } ``` Add any stateful service to the ops box and the snapshot still succeeds while containing nothing of it. `deploy/UPGRADES.md` makes that exit code the gate for every ops upgrade — "no copy, no upgrade" — so the gate would be passing on a copy that is missing the thing being upgraded. This surfaced while designing a feedback board for the ops box. **It is worth fixing regardless of whether that board is ever built**, which is why it is filed on its own rather than inside it. Today the box happens to have one stateful service, so nothing is lost right now. The failure is that adding the second is silent. ## What to do A **completeness assertion**. The script already enumerates services for the manifest at line 87: ```sh for svc in $(docker compose config --services); do ``` Have it also fail when a declared service is in neither a `BACKED_UP` nor a `STATELESS` list. Adding a service then forces a deliberate choice instead of a silent omission. Then cross-check the lists from a test — the idiom this repository already uses twice. `inventory.mjs` keeps `HOST_FILES` identical to `install-deployer.sh`'s `CHECKED_FILES` with a test that reads the file, for the stated reason that *two checkers disagreeing about what healthy means is how the ops box stayed unswept*; `console.test.ts` does the same for `UPGRADEABLE` against `parsePins`. `deploy/test/snapshot.test.ts`: read `snapshot.sh` and `deploy/ops/docker-compose.yml`, assert every declared service is accounted for in one list or the other. ## Verification **Mutation-check it, in both directions.** Feed a compose fixture containing an unlisted service and confirm the test **fails**; then confirm it passes on the real file. A test that has never failed proves nothing, and that is the whole point of this issue.

cruelacid added this to the Backlog - unscheduled milestone

2026-09-23 10:46:22 +01:00

cruelacid added the

area:ops

label

2026-09-23 10:46:22 +01:00

cruelacid referenced this issue

2026-09-23 10:46:56 +01:00

Go-to-market programme #110

cruelacid commented

2026-09-23 18:55:54 +01:00

Author