rve/learning-platform
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Frontend crash-loopt: ongeldige respond-subdirective in Caddyfile (app volledig offline ondanks groene CI) #20

New Issue
Closed
opened 2026-07-11 12:21:01 +00:00 by rve · 0 comments
rve commented 2026-07-11 12:21:01 +00:00
Owner
Copy Link

Symptoom

De applicatie is voor gebruikers volledig offline (ook de frontend), terwijl álle CI-runs groen zijn — inclusief de nieuwe PocketBase-health-gate uit #18/PR #19.

Root cause (bewezen)

Commit 89d3395 (vanochtend 10:19, direct op main) voegde aan het productie-Caddyfile een handle_errors-blok toe met:

respond @api `{"code":{err.status_code},"message":"Backend unavailable"}` {err.status_code} {
    Content-Type application/json
}

respond accepteert alleen body/close als subdirectives — Content-Type hoort in een losse header-directive. Dit is een Caddyfile-parse-fout; Caddy weigert te starten en de learning-platform-container crash-loopt. Empirisch bevestigd met Caddy v2.10.0:

Error: adapting config using caddyfile: parsing caddyfile tokens for 'handle_errors':
parsing caddyfile tokens for 'respond': unrecognized subdirective 'Content-Type', at Caddyfile:53

Tijdlijn: het eerste image met dit Caddyfile is om 08:21Z gebouwd en 08:23Z gedeployed (run #88). Elke run daarna (#89, #90, #91) hergebruikte de kapotte config → de frontend is sinds ±08:25Z down. De buitenste proxy geeft anonieme bezoekers gewoon een 302 naar de auth-gate, dus van buiten lijkt alles normaal; ingelogde gebruikers krijgen niets.

Waarom CI dit niet zag (twee blinde vlekken)

  1. test.yml test nooit het echte Caddyfile: het testimage vervangt het door Caddyfile.test (COPY Caddyfile.test /etc/caddy/Caddyfile). Een parse-fout in het productiebestand komt dus door de test-job heen.
  2. De deploy-health-gate (#18) checkt alleen PocketBase, niet de frontend-container.

Fix

  1. Caddyfile: Content-Type als header @api-directive vóór de respond (gevalideerd met caddy validate, config nu Valid; Caddyfile.test ook gecontroleerd).
  2. Beide deploy-playbooks: frontend-health-gate (docker exec learning-platform wget --spider http://127.0.0.1:80/, met log-dump en abort bij falen) + post-deploy smoke-report in de CI-log: docker compose ps, interne proxy-health, auth-methods (is de OIDC-provider echt geconfigureerd?), PocketBase-logtail — de zichtbaarheid achter de perimeter die vandaag ontbrak.

Follow-up (buiten deze fix, ter overweging)

  • caddy validate van het échte Caddyfile opnemen in test.yml (workflow is frozen; bewuste keuze voor de reviewer).
  • Overwegen of directe pushes naar main langs een PR-check moeten.

Verificatie

  • caddy validate op gefixt Caddyfile: Valid
  • PR-pipeline: image herbouwd, deploy-dev groen incl. beide gates
  • Smoke-report toont: beide containers Up, proxy-health OK, OIDC-provider aanwezig
  • Gebruiker bevestigt: app bereikbaar en login werkt

Gerelateerd: #18, PR #19 (health-gate PocketBase), run #86 (eerdere diagnostiek).

## Symptoom De applicatie is voor gebruikers **volledig offline** (ook de frontend), terwijl álle CI-runs groen zijn — inclusief de nieuwe PocketBase-health-gate uit #18/PR #19. ## Root cause (bewezen) Commit `89d3395` (vanochtend 10:19, direct op main) voegde aan het **productie-`Caddyfile`** een `handle_errors`-blok toe met: ```caddyfile respond @api `{"code":{err.status_code},"message":"Backend unavailable"}` {err.status_code} { Content-Type application/json } ``` `respond` accepteert alleen `body`/`close` als subdirectives — `Content-Type` hoort in een losse `header`-directive. Dit is een **Caddyfile-parse-fout**; Caddy weigert te starten en de `learning-platform`-container crash-loopt. Empirisch bevestigd met Caddy v2.10.0: ``` Error: adapting config using caddyfile: parsing caddyfile tokens for 'handle_errors': parsing caddyfile tokens for 'respond': unrecognized subdirective 'Content-Type', at Caddyfile:53 ``` **Tijdlijn:** het eerste image met dit Caddyfile is om 08:21Z gebouwd en 08:23Z gedeployed (run #88). Elke run daarna (#89, #90, #91) hergebruikte de kapotte config → de frontend is sinds ±08:25Z down. De buitenste proxy geeft anonieme bezoekers gewoon een 302 naar de auth-gate, dus van buiten lijkt alles normaal; ingelogde gebruikers krijgen niets. ## Waarom CI dit niet zag (twee blinde vlekken) 1. **`test.yml` test nooit het echte Caddyfile**: het testimage vervangt het door `Caddyfile.test` (`COPY Caddyfile.test /etc/caddy/Caddyfile`). Een parse-fout in het productiebestand komt dus door de test-job heen. 2. **De deploy-health-gate (#18) checkt alleen PocketBase**, niet de frontend-container. ## Fix 1. `Caddyfile`: `Content-Type` als `header @api`-directive vóór de `respond` (gevalideerd met `caddy validate`, config nu **Valid**; `Caddyfile.test` ook gecontroleerd). 2. Beide deploy-playbooks: **frontend-health-gate** (`docker exec learning-platform wget --spider http://127.0.0.1:80/`, met log-dump en abort bij falen) + **post-deploy smoke-report** in de CI-log: `docker compose ps`, interne proxy-health, `auth-methods` (is de OIDC-provider echt geconfigureerd?), PocketBase-logtail — de zichtbaarheid achter de perimeter die vandaag ontbrak. ## Follow-up (buiten deze fix, ter overweging) - `caddy validate` van het échte `Caddyfile` opnemen in `test.yml` (workflow is frozen; bewuste keuze voor de reviewer). - Overwegen of directe pushes naar main langs een PR-check moeten. ## Verificatie - [x] `caddy validate` op gefixt `Caddyfile`: Valid - [ ] PR-pipeline: image herbouwd, deploy-dev groen incl. **beide** gates - [ ] Smoke-report toont: beide containers Up, proxy-health OK, OIDC-provider aanwezig - [ ] Gebruiker bevestigt: app bereikbaar en login werkt Gerelateerd: #18, PR #19 (health-gate PocketBase), run #86 (eerdere diagnostiek).
rve closed this issue 2026-07-12 15:11:25 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
eho lmi lpr not rdi rve
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: rve/learning-platform#20
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?