fix(disk-delete): launcher leest de database uit DATABASE_URL #87

Merged
janpeter merged 1 commit from fix/disk-delete-launcher-database-name into main 2026-09-21 23:22:41 +02:00
Owner

De disk-delete-launcher had de databasenaam hardgecodeerd op media_organizer, terwijl de app op media_organizer_v2 draait (PR #79). Beide databases bestaan op max2; de oude heeft geen disk_delete%-tabellen.

Gemeten op max2 (live, vóór deze wijziging)

De exacte query uit de launcher tegen de hardgecodeerde database:

ERROR:  relation "disk_delete_work" does not exist
exit=1

Daardoor faalde al de eerste psql-aanroep van elke tick (reconcile_stale) op || fail en eindigde de launcher op disk_delete_launcher_failed. Fail-closed, dus er is nooit iets verwijderd — maar ook mét een geactiveerde timer zou de feature nooit een opdracht verwerken. Op dit moment staan er 100 opdrachten op queued (2026-09-21 20:48 UTC), 0 auditregels, 0 slotrijen, en alle 100 bestanden staan nog op schijf (present=100 missing=0).

Wijziging

  • De naam komt uit de enige bron van waarheid: DATABASE_URL in deploy/media-organizer.env — dezelfde env die de delete-worker krijgt. De env-file wordt geparsed, niet ge-sourced (hij bevat geheimen). Quotes, een CRLF-regeleinde en een ?schema=…-querystring worden afgepeld.
  • Een onbepaalbare naam is fail-closed met een eigen code (disk_delete_db_name_unresolved); er is geen terugval op een vaste naam.
  • De psql-array houdt -c als laatste element (MAJOR 3 uit ronde 3 blijft gedekt).

Waarom geen test dit zag

disk-delete-launcher-exec.test.ts faket docker maar las het -d-argument niet, en disk-delete-launcher.test.ts is een parsetest op de scripttekst. De fake registreert de gebruikte database nu in een bestand en twee regressies toetsen hem.

Verificatie

node --test src/test/disk-delete-launcher-exec.test.ts — 4/4 groen met deze wijziging.

Discriminatie bewezen: met de oude launcher en de nieuwe tests zijn beide regressies rood op de juiste grond (verkeerde database in -d: media_organizer, media_organizer), terwijl de twee bestaande tests groen blijven. De parse-asserties van disk-delete-launcher.test.ts zijn los nagerekend tegen het gewijzigde script (-c als laatste: true, geen -tAqc: true, statusset 'queued','running','deleted', reaper-regex: true).

Het runbook-recept voor de losse databasecontrole is met een fixture-env-file uitgevoerd en geeft media_organizer_v2.

Runbook

Toegevoegd: een verplichte eerste-tick-controle. systemctl enable --now bewijst niets — een timer die elke minuut faalt ziet er in list-timers identiek uit als een werkende. De stap eist Result=success + ExecMainStatus=0 en geeft het losse psql-recept, met de expliciete waarschuwing dat relation "disk_delete_work" does not exist betekent dat je de verkeerde database raakt en niet dat de migratie ontbreekt.

Niet in deze PR

  • De systemd-units staan nog niet geïnstalleerd op max2; activering blijft een aparte JP-beslissing.
  • De 100 queued-opdrachten blijven staan. Zodra de timer aan gaat verwijdert de eerste tick ze definitief — ruim ze eerst op als dat niet de bedoeling is.

🤖 Generated with Claude Code

De disk-delete-launcher had de databasenaam hardgecodeerd op `media_organizer`, terwijl de app op `media_organizer_v2` draait (PR #79). Beide databases bestaan op max2; de oude heeft geen `disk_delete%`-tabellen. ## Gemeten op max2 (live, vóór deze wijziging) De exacte query uit de launcher tegen de hardgecodeerde database: ``` ERROR: relation "disk_delete_work" does not exist exit=1 ``` Daardoor faalde al de eerste psql-aanroep van elke tick (`reconcile_stale`) op `|| fail` en eindigde de launcher op `disk_delete_launcher_failed`. Fail-closed, dus er is nooit iets verwijderd — maar ook mét een geactiveerde timer zou de feature nooit een opdracht verwerken. Op dit moment staan er 100 opdrachten op `queued` (2026-09-21 20:48 UTC), 0 auditregels, 0 slotrijen, en alle 100 bestanden staan nog op schijf (`present=100 missing=0`). ## Wijziging - De naam komt uit de enige bron van waarheid: `DATABASE_URL` in `deploy/media-organizer.env` — dezelfde env die de `delete-worker` krijgt. De env-file wordt **geparsed, niet ge-sourced** (hij bevat geheimen). Quotes, een CRLF-regeleinde en een `?schema=…`-querystring worden afgepeld. - Een onbepaalbare naam is fail-closed met een eigen code (`disk_delete_db_name_unresolved`); er is geen terugval op een vaste naam. - De `psql`-array houdt `-c` als laatste element (MAJOR 3 uit ronde 3 blijft gedekt). ## Waarom geen test dit zag `disk-delete-launcher-exec.test.ts` faket `docker` maar las het `-d`-argument niet, en `disk-delete-launcher.test.ts` is een parsetest op de scripttekst. De fake registreert de gebruikte database nu in een bestand en twee regressies toetsen hem. ## Verificatie `node --test src/test/disk-delete-launcher-exec.test.ts` — 4/4 groen met deze wijziging. Discriminatie bewezen: met de **oude** launcher en de **nieuwe** tests zijn beide regressies rood op de juiste grond (`verkeerde database in -d: media_organizer, media_organizer`), terwijl de twee bestaande tests groen blijven. De parse-asserties van `disk-delete-launcher.test.ts` zijn los nagerekend tegen het gewijzigde script (`-c` als laatste: true, geen `-tAqc`: true, statusset `'queued','running','deleted'`, reaper-regex: true). Het runbook-recept voor de losse databasecontrole is met een fixture-env-file uitgevoerd en geeft `media_organizer_v2`. ## Runbook Toegevoegd: een verplichte eerste-tick-controle. `systemctl enable --now` bewijst niets — een timer die elke minuut faalt ziet er in `list-timers` identiek uit als een werkende. De stap eist `Result=success` + `ExecMainStatus=0` en geeft het losse psql-recept, met de expliciete waarschuwing dat `relation "disk_delete_work" does not exist` betekent dat je de verkeerde database raakt en niet dat de migratie ontbreekt. ## Niet in deze PR - De systemd-units staan nog **niet** geïnstalleerd op max2; activering blijft een aparte JP-beslissing. - De 100 `queued`-opdrachten blijven staan. Zodra de timer aan gaat verwijdert de eerste tick ze definitief — ruim ze eerst op als dat niet de bedoeling is. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
fix(disk-delete): launcher leest de database uit DATABASE_URL
All checks were successful
CI / test (historical-bootstrap) (pull_request) Successful in 1m5s
CI / test (video-migration) (pull_request) Successful in 1m6s
CI / test (suite) (pull_request) Successful in 3m42s
CI / docker-build (pull_request) Successful in 2m45s
9da7f9282d
De launcher had `-d media_organizer` hardgecodeerd terwijl de app op
`media_organizer_v2` draait (PR #79). Beide databases bestaan op max2; de
oude heeft geen `disk_delete%`-tabellen, dus de eerste psql-aanroep van elke
tick faalde met `relation "disk_delete_work" does not exist` en de launcher
eindigde op `disk_delete_launcher_failed`. Fail-closed, maar daardoor zou de
feature ook met een geactiveerde timer nooit een opdracht verwerken.

De naam komt nu uit de enige bron van waarheid: `DATABASE_URL` in
`deploy/media-organizer.env`, dezelfde env die de `delete-worker` krijgt. De
env-file wordt geparsed, niet ge-sourced (hij bevat geheimen). Een
onbepaalbare naam is fail-closed met een eigen code
(`disk_delete_db_name_unresolved`), geen terugval op een vaste naam.

De bestaande launchertests faken `docker` zonder het `-d`-argument te lezen,
dus geen enkele test zag dit. De fake registreert de database nu en twee
regressies toetsen hem: met de oude launcher zijn ze rood op de juiste grond
(`verkeerde database in -d: media_organizer`), met de nieuwe groen.

Het runbook kreeg een verplichte eerste-tick-controle: `enable --now` bewijst
niets, want een elke minuut falende timer ziet er in `list-timers` identiek
uit. De stap toetst `Result=success` en geeft het losse psql-recept om de
database te controleren.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
s4m-codex-reviewer left a comment

Verdict: APPROVED

Geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden.

Findings

Geen blokkerende of error-severity findings gevonden.

Review

De wijziging houdt de disk-delete launcher fail-closed en haalt de databasenaam uit dezelfde runtime-env (deploy/media-organizer.env) als de delete-worker. Daarmee verdwijnt de hardgecodeerde media_organizer-koppeling zonder de env-file te sourcen of secrets uit te voeren. De validatie op de afgeleide databasenaam voorkomt een stille fallback bij een onbruikbare DATABASE_URL.

De toegevoegde executietest controleert expliciet het psql -d argument en vangt regressie naar een vaste databasenaam af. De runbook-aanvulling past bij de productstandaard voor de korte, fail-closed delete-worker en maakt de eerste timer-tick verifieerbaar.

# Verdict: APPROVED Geen gekoppeld plan gevonden — beoordeeld op codekwaliteit + product-standaarden. ## Findings Geen blokkerende of error-severity findings gevonden. ## Review De wijziging houdt de disk-delete launcher fail-closed en haalt de databasenaam uit dezelfde runtime-env (`deploy/media-organizer.env`) als de delete-worker. Daarmee verdwijnt de hardgecodeerde `media_organizer`-koppeling zonder de env-file te sourcen of secrets uit te voeren. De validatie op de afgeleide databasenaam voorkomt een stille fallback bij een onbruikbare `DATABASE_URL`. De toegevoegde executietest controleert expliciet het `psql -d` argument en vangt regressie naar een vaste databasenaam af. De runbook-aanvulling past bij de productstandaard voor de korte, fail-closed delete-worker en maakt de eerste timer-tick verifieerbaar.
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
janpeter/Media-Organizer!87
No description provided.