ehoandClaude Opus 5
12f17d9d73
Two backlog trees are complete: `docs/project/backlog/` (75 files, every WP done) and `docs/project/refactor-backlog-setup/` (the arc before it). Move both under `docs/project/archive/` with `git mv`, so history stays intact through `git log --follow`. `SHOWCASE-ROADMAP.md` moves with them, because it points at the now-archived backlog README. Add `docs/project/archive/README.md`. It states that these trees are historical and names the two directories that are still live. Repoint every inbound reference named in RD-30's Files table: CLAUDE.md, the root README, both backend READMEs, `LetterHtml.cs`, `a11y.mdx`, the `document-feature` and `new-ssp` skills, and the readable-codebase PLAN, README, and RD-19 ticket. Fix two upward-relative links inside the moved WP files (WP-68, WP-69) that gained a directory level and would otherwise break. Repoint `.prettierignore`'s two agent-prompt exclusions to their new path, so prettier keeps leaving those files' exact wording alone. Mark RD-30 done and check off its acceptance criteria; flip its README row to done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.3 KiB
RB-05 — drop the BSN-bearing query and body snippet from the ZGW failure message
Status: implemented · 2026-08-27 · Source findings: 07-bio2-compliance.md BIO-009 · 99-backlog.md RB-05
What was wrong
ZgwHttpClient.SendWithRetryAsync built its failure message as
$"ZGW {req.Method} {req.RequestUri} failed: {(int)res.StatusCode} {snippet}"
with snippet being up to 500 characters of the response body. That message is not
transient: Program.cs's submit endpoint catches it and stores it as Aanvraag.ZgwError
in SQLite, and logs it.
Two BSN paths into it:
- the query string. ZGW filters travel as query parameters, and the citizen-scoped zaken
list filters on
rol__betrokkeneIdentificatie__natuurlijkPersoon__inpBsn=<BSN>. - the body snippet. OpenZaak's error responses echo the offending request, so a rejected
POST /rollen(whose body carriesBetrokkeneIdentificatie(aanvraag.Owner)) comes back with the BSN in it.
The two "returned null body" throws in GetAsync/PostAsync interpolated the same url.
What changed
| File | Change |
|---|---|
Zgw/ZgwHttpClient.cs |
Redact(url) (path only) at all three sites; snippet → res.ReasonPhrase |
ZgwDivergenceTests.cs |
new A_recorded_divergence_carries_no_response_body_and_no_query_string |
Status + path is enough to route a failure to the right endpoint. The diagnostic detail
that was lost already has a deliberate home: ZGW_DEBUG_HTTP=1 wires
ZgwDiagnosticHandler, which logs the full url and request bytes — opt-in, dev-only, and
not persisted.
The test
Fails the statustypen GET (the only call in that fixture whose url carries a query
string) after the zaak POST succeeds, then asserts on the persisted ZgwError:
no "stub failure" (the body snippet), no "?" (the query string), but still the path and
the 503. Confirmed it fails without the fix — restoring the old interpolation turns it
red on both counts.
Verification
dotnet format --verify-no-changes clean. dotnet test: 253 passed, 1 failed — the
pre-existing OpenZaakIntegrationTests.Admin_cases_…, which needs a live container.