ehoandClaude Sonnet 5
ba24784586
CI / changes (push) Successful in 8s
CI / lint (push) Successful in 55s
CI / frontend (push) Successful in 1m33s
CI / backend (push) Successful in 1m46s
CI / e2e (push) Successful in 3m14s
CI / storybook-a11y (push) Successful in 6m50s
CI / semgrep (push) Successful in 1m13s
CI / api-client-drift (push) Successful in 1m47s
scripts/openzaak-ui-up.sh brings up the root app and the OpenZaak harness together, wires them onto one docker network, seeds the catalogus, grants the container-alias zaaktype scope, and verifies a real aanvraag submitted through the UI lands in OpenZaak. Along the way: DocumentStore.DemoOwner was reusing the seeded doctor's 11-digit BIG-nummer as a stand-in BSN, which isn't a valid 9-digit BSN shape — OpenZaak rejects it, breaking both submit's rol-creation step and the citizen's own applications list under Zgw:Enabled=true. Fixed to a real elfproef-valid BSN. Also adds mitigation for a still-unexplained per-container flake (every outbound ZGW POST fails as if the body were empty, for that container's whole lifetime) that correlates with host memory pressure: the script now warns when host swap is heavily used, and an opt-in ZgwDiagnosticHandler (ZGW_DEBUG_HTTP=1) logs Content-Length vs. actual bytes sent so the next reproduction can confirm or rule out client-side body corruption. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
39 lines
2.2 KiB
YAML
39 lines
2.2 KiB
YAML
# Opt-in overlay, layered ON TOP of docker-compose.openzaak.yml (never alone):
|
|
#
|
|
# docker compose -f docker-compose.openzaak.yml -f docker-compose.openzaak.bff.yml up -d
|
|
#
|
|
# Gives this harness's `web` (the OpenZaak API) an extra, dotted hostname alias
|
|
# (`openzaak.local`) on its OWN network, so the root project's `api` container (joined in via
|
|
# `docker-compose.openzaak.yml` at the repo root, as an EXTERNAL network) can reach it. See
|
|
# `scripts/openzaak-ui-up.sh` for the one-command version that brings both projects up
|
|
# together, seeds the catalogus, and grants the extra authorization scope this alias needs.
|
|
#
|
|
# Three real things this works around, each discovered empirically (curl against the
|
|
# running containers), not guessed:
|
|
#
|
|
# 1. Why container-to-container instead of `http://localhost:8000`: this dev environment's
|
|
# rootless Podman drops container→host-port traffic through `host.docker.internal`
|
|
# (confirmed for the WP-58 notifications overlay's celery worker — DNS resolves it, every
|
|
# TCP connect times out).
|
|
#
|
|
# 2. Why the ROOT project's `api` joins INTO this project's network (below), not the other way
|
|
# around: the root project's frontend service is also called `web`. Docker Compose always
|
|
# adds a service's own name as a network alias on every network it joins — so if THIS `web`
|
|
# joined the root project's network, "web" would resolve to two different containers there.
|
|
# Only `api` crosses into this network, under its own already-unique name.
|
|
#
|
|
# 3. Why the alias has a dot in it (`openzaak.local`, not e.g. `openzaak`): Django's built-in
|
|
# URLValidator rejects a bare, dotless hostname in a URL field (it special-cases exactly
|
|
# "localhost"; anything else needs a dot or to be a valid IP). OpenZaak's `zaaktype` field
|
|
# (and others) run through this validator — confirmed with a POST referencing
|
|
# `http://<dotless-alias>:8000/...` failing "Voer een geldige URL in" (enter a valid URL)
|
|
# before any authorization check even runs.
|
|
services:
|
|
web:
|
|
environment:
|
|
# Django rejects any request whose Host header isn't in ALLOWED_HOSTS.
|
|
ALLOWED_HOSTS: localhost,127.0.0.1,web,openzaak.local
|
|
networks:
|
|
default:
|
|
aliases: [openzaak.local]
|