Compare commits

...
Author SHA1 Message Date
not b30fa664d8 feat(event-subscriber): accept partial_update as a register write (refs #153)
CI / lint (pull_request) Successful in 1m25s
CI / build (pull_request) Successful in 1m14s
CI / unit (pull_request) Successful in 1m26s
CI / frontend (pull_request) Successful in 3m7s
CI / mutation (pull_request) Successful in 6m13s
CI / verify-stack (pull_request) Successful in 9m32s
The ACL upserts with PATCH, so every approval notification carries actie `partial_update`.
Accepting it makes the INGEDIEND → INGESCHREVEN transition project. `update` stays accepted
so a PUT-shaped write behaves the same; `destroy` deliberately does not — removing a
registration from the public register is its own decision, not a side effect of this one.

ADR-0030 records why the actie list is what it is.
2026-08-28 13:40:01 +02:00
not 0dd26a711a test(event-subscriber): approval arrives as partial_update, not update (refs #153)
The e2e reached INGEDIEND but never INGESCHREVEN. NRC's own log says why:

  {"event": "notification_received", "action": "partial_update",
   "resource_url": "http://objecten.local:8000/api/v2/objects/a9a7f125-..."}

The ACL PATCHes the object on approval. DRF routes a PATCH through the notifying `update()`
but reports the action as `partial_update`, so accepting only `create`/`update` drops every
approval on the floor — the exact state change the slice exists to project.

Red: the approval case is now a Theory over both acties, and the partial_update one fails.
2026-08-28 13:39:03 +02:00
3 changed files with 28 additions and 8 deletions
@@ -34,6 +34,12 @@ notification points at. The projection is a cache of the register; ZGW is no lon
as a kenmerk — so the record is read back through the ACL (`POST /register-records/read`).
§8.1 applies to Objecten exactly as ADR-0028 established: the ACL is the only code that talks
to it.
- The accepted acties are `create`, `update` and `partial_update`. The last one is not
defensive breadth: the ACL upserts with PATCH, and DRF routes a PATCH through the notifying
`update()` while naming the action `partial_update` — which is what Objecten publishes. So
every approval arrives as `partial_update`, and accepting only `create`/`update` drops the
one state change this slice exists to project. `destroy` is deliberately not accepted:
removing a registration from the public register is its own decision.
- The record already carries `id`, `status` and `reference`, so the row is the record. The
zaak-shaped surface goes: `IsZaakCreated`, `IsZaakStatusSet`, `ZaakUrl`, `ZaakId`, and
`ToEntry`'s `Resource == "status"` inference are replaced by `IsRegisterRecordWritten` +
@@ -18,10 +18,20 @@ public sealed record Notification(
string Actie,
Uri ResourceUrl)
{
/// <summary>A register record written to Objecten — <c>create</c> on submit, <c>update</c> on
/// approval, since the ACL upserts the same object for a registration (§8.6).</summary>
/// <summary>
/// A register record written to Objecten — <c>create</c> on submit and <c>partial_update</c> on
/// approval, since the ACL upserts the same object for a registration (§8.6).
/// </summary>
/// <remarks>
/// <c>partial_update</c> is what a PATCH actually reports: DRF routes it through the notifying
/// <c>update()</c> but names the action <c>partial_update</c>, and that is what Objecten puts in
/// the notification. <c>update</c> is accepted too, so a PUT-shaped write would project the same
/// way. <c>destroy</c> is deliberately not: removing a registration from the public register is
/// its own decision, not a side effect of this one.
/// </remarks>
public bool IsRegisterRecordWritten =>
Kanaal == "objecten" && Resource == "object" && Actie is "create" or "update";
Kanaal == "objecten" && Resource == "object"
&& Actie is "create" or "update" or "partial_update";
/// <summary>The object holding the register record. For a <c>resource: object</c> notification
/// Objecten sends the object as both <c>hoofdObject</c> and <c>resourceUrl</c> — the object is
@@ -38,13 +38,17 @@ public sealed class NotificationProjectorTests
Assert.Equal("REG-2026-0001", entry.Reference);
}
[Fact]
public async Task approval_updates_the_same_row_from_ingediend_to_ingeschreven()
// The ACL PATCHes the same object on approval. DRF routes a PATCH through `update()` but reports
// the action as `partial_update`, which is what Objecten puts in the notification — so accepting
// only `create`/`update` silently drops every approval.
[Theory]
[InlineData("partial_update")]
[InlineData("update")]
public async Task approval_updates_the_same_row_from_ingediend_to_ingeschreven(string actie)
{
var projector = Projector();
await projector.HandleAsync(RecordWritten());
// The ACL PATCHes the same object on approval, so Objecten publishes an `update`.
await projector.HandleAsync(RecordWritten("update", status: RegistrationStatus.Ingeschreven));
await projector.HandleAsync(RecordWritten(actie, status: RegistrationStatus.Ingeschreven));
var entry = Assert.Single(await _store.AllAsync());
Assert.Equal(ZaakId, entry.Id);
@@ -112,7 +116,7 @@ public sealed class NotificationProjectorTests
{
var projector = Projector();
await projector.HandleAsync(RecordWritten());
await projector.HandleAsync(RecordWritten("update", status: RegistrationStatus.Ingeschreven));
await projector.HandleAsync(RecordWritten("partial_update", status: RegistrationStatus.Ingeschreven));
var callsAfterProjection = _acl.CallCount;
await projector.RebuildAsync();