feat(openzaak): one-command UI-OpenZaak bridge, real BSN fix, flake mitigation
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
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>
This commit is contained in:
@@ -0,0 +1,28 @@
|
||||
using System.Net.Http.Json;
|
||||
using BigRegister.Api.Zgw;
|
||||
using Microsoft.Extensions.Logging.Abstractions;
|
||||
|
||||
namespace BigRegister.Tests;
|
||||
|
||||
/// <summary>
|
||||
/// The opt-in diagnostic handler (see ZgwDiagnosticHandler's own doc comment) must be inert on
|
||||
/// the request/response — it only observes. This doesn't catch the flake itself (that needs a
|
||||
/// real repro with ZGW_DEBUG_HTTP=1), just proves the hook doesn't alter what's sent or break
|
||||
/// the response passthrough.
|
||||
/// </summary>
|
||||
public class ZgwDiagnosticHandlerTests
|
||||
{
|
||||
[Fact]
|
||||
public async Task Passes_request_and_response_through_unchanged()
|
||||
{
|
||||
var stub = new ZgwStubHandler(_ => """{ "ok": true }""");
|
||||
var diagnostic = new ZgwDiagnosticHandler(NullLogger<ZgwDiagnosticHandler>.Instance) { InnerHandler = stub };
|
||||
using var client = new HttpClient(diagnostic);
|
||||
|
||||
var response = await client.PostAsJsonAsync("https://oz.example/zaken", new { foo = "bar" });
|
||||
|
||||
Assert.True(response.IsSuccessStatusCode);
|
||||
Assert.Single(stub.Requests);
|
||||
Assert.Contains("\"foo\":\"bar\"", stub.BodyOf("https://oz.example/zaken"));
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user