feat(infra): Objecten publishes register events to NRC (closes #152) #154

Merged

not merged 4 commits from feat/152-objecten-publishes-to-nrc into main 2026-08-28 10:11:55 +00:00

Conversation 0 Commits 4 Files Changed 12

+438 -22

4 Commits

Author	SHA1	Message	Date
not	a5fd47e546	fix(infra): correlate the delivery on the object URL, not the record reference (refs #152) ... The publish chain works — the sink received it: {"kanaal": "objecten", "resource": "object", "kenmerken": {"objectType": "…"}, "hoofdObject": "http://objecten.local:8000/api/v2/objects/a68d4c46-…", …} The check just looked for the wrong thing. An NRC notification carries hoofdObject / resourceUrl and kenmerken — never the record data — so the `reference` inside the RegisterRecord it wrote was never going to appear in the delivered message. Grep the sink for the object URL instead, which is what identifies the write.	2026-08-28 11:50:07 +02:00
not	d76abf2df2	fix(infra): address Objecten by a dotted host so NRC accepts its notifications (refs #152) ... The worker published and NRC answered 400 on every message: {"hoofdObject":["Voer een geldige URL in."],"resourceUrl":["Voer een geldige URL in."]} NRC types both as DRF `URLField`, and Django's URLValidator refuses a single-label host. Objecten fills them from the object `url` DRF built with `request.build_absolute_uri` — the Host the *caller* used — so `SITE_DOMAIN` never entered into it. Dropped that env pair; it was a wrong guess at the mechanism. The fix is on the caller side: keep the `objecten.local` network alias and point every writer whose writes must be notified at it — the ACL, the gateway integration tests, and this slice's verify driver. Readers keep the plain service name. ADR-0029 updated with the real mechanism and the ceiling it leaves: a new writer using `objecten:8000` gets a 201 and silently no notification.	2026-08-28 11:31:31 +02:00
not	448896206f	feat(infra): Objecten publishes register events to NRC (refs #152) ... Builds the four pieces ADR-0028 deliberately left absent, and turns `NOTIFICATIONS_DISABLED` back off: - `objecten-celery`, a worker on the Objecten image (mirrors `oz-celery`), plus `CELERY_BROKER_URL`/`RESULT_BACKEND` on objecten-redis db 1 (db 0 is the cache). Without it `notifications_api_common` queues the send and nothing ever ships it. - An `nrc` service + `notifications_config` in Objecten's setup_configuration, reusing the `big-reference-seed` credential OpenZaak publishes with. - The `objecten` kanaal in NRC's setup_configuration — the name is fixed by the Objects API (`NOTIFICATIONS_KANAAL`), and publishing to an unregistered kanaal is what the failing check reported first. - `SITE_DOMAIN: objecten.local:8000` + an `objecten.local` network alias: NRC validates `hoofdObject`/`resourceUrl` with Django's URLValidator, which rejects a single-label host, so `objecten:8000` is refused with "Voer een geldige URL in." The alias keeps the dotted host resolvable so the URL still dereferences. ADR-0029 records it; ADR-0028's ceiling now points there. Makes `make verify-objecten-notifications` (dc9ca2c) pass.	2026-08-28 10:54:14 +02:00
not	dc9ca2ceb2	test(infra): verify-objecten-notifications asserts Objecten publishes to NRC (refs #152) ... Registers an abonnement on the `objecten` kanaal pointing at the existing webhook sink, writes a RegisterRecord exactly as the ACL does on approval, and waits for the delivery. That is the whole publish chain in one assertion: Objecten → its celery worker → NRC → nrc-beat → the callback. Fails today at the first hop, which is the point: NRC POST /api/v1/abonnement → 400: {"name":"naam","code":"kanaal_naam", "reason":"Kanaal met deze naam bestaat niet."} Also splits S-19b (#150) into #152/#153 in BACKLOG.md — the notification wiring and the projection re-source are independently deployable (CLAUDE.md §13).	2026-08-14 11:50:16 +02:00