The status-set integration test hit 400 "resultaat-does-not-exist: Zaak has no
resultaat" — OpenZaak refuses a zaak's eindstatus until the zaak has a resultaat.
Resolve the zaaktype's resultaattype and POST /resultaten before POST /statussen.
Also surface the ZGW response body in the failure exception (EnsureSuccessStatusCode
hid the 400 detail that pinpointed this). Reworked the gateway with shared
GetCatalogusAsync/PostAsync helpers and rewrote the stub-handler tests for the new
4-call flow incl. failure paths. Verified against real OpenZaak (integration test
green) and locally: acl mutation 100%.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The gateway resolves the zaaktype's eindstatus from the catalogus (isEindstatus,
falling back to the highest volgnummer) and POSTs a status against the zaak. Exposed
as POST /statussen for the domain's approve use case. Adds an integration test that
sets the eindstatus against a real OpenZaak and verifies the zaak's current status.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
OpenZaak runs behind uwsgi, which rejects a chunked request body with 400.
JsonContent streams without a Content-Length (Transfer-Encoding: chunked), so
buffer it first. Only a real OpenZaak surfaces this — the integration test from
the previous commit now passes. A unit test asserts a Content-Length is sent
(captured before the stub reads/buffers the body), guarding the fix in the fast
lane and killing the Stryker mutant that would otherwise survive.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
