Projectiefout hersteld via replay
Na terugmelding blijkt dat er een bug in 1 van de projecties zit: de gevolgen zijn goed vastgelegd; deze zijn echter niet goed zichtbaar in de projectie. Bij een overdracht wordt alleen de 1e eigenaar vastgelegd.
- WOZ Object wordt geregistreerd.
- Er vindt een overdracht plaats.
- Iemand (een afnemer?) merkt op dat er een specifieke projectie op een specifiek snapshot onjuist is en meldt dat terug (met bij voorkeur een UUID van de projectie). Er wordt een onderzoek gestart, en uit dat onderzoek blijkt dat er een bug in de projectie zit: verwerking is goed gegaan en gevolgen zijn correct.
- Het ontwikkel/beheerteam fixt de bug en doet een replay op de snapshots: voor de foutsituatie worden nieuwe snapshots geproduceerd.
- Onderzoek wordt afgerond.
Brondata
ReplayVoorbeeldTest-als-een-projectieview-verandert-naar-aanleiding-van-een-replay-wordt-de-oude-overschreven.jsonCommitd6c2994Opgehaald20 mei 2026Dit voorbeeld lijkt op het vorige — onderzoek en herstel — maar heeft een wezenlijk andere oorzaak. Daar lag de fout in de brondata zelf: het BRK-bericht bevatte een onjuiste naam. Hier zijn de events correct opgeslagen, maar bevat de projectiecode een bug. Die oorzaak bepaalt de herstelstrategie: niet een correctie-event, maar een replay.
De bug
De projectiecode bevat een fout in de verwerking van het gevolg BelangOvergegaanNavOverdracht. Bij een overdracht naar meerdere partijen legt de projectie alleen de eerste partij vast. De overige partijen worden overgeslagen. Gevolg: de snapshot die wordt aangemaakt na de overdracht toont een onvolledig beeld — de gerelateerdePartijen bevat maar één eigenaar (Piet Pietersen), terwijl de overdracht naar twee partijen plaatsvond.
Het is belangrijk om te begrijpen wat er niet mis is: de events zelf zijn correct opgeslagen. Het gevolg BelangOvergegaanNavOverdracht bevat de juiste lijst met partijen. De fout zit uitsluitend in de manier waarop de projectie het gevolg verwerkt en vastlegt als snapshot. De brondata is betrouwbaar; de weergave is dat niet.
Ontdekking en onderzoek
Een afnemer bevraagt het systeem en constateert dat een snapshot onjuiste belangen toont: er ontbreekt een eigenaar na een eigendomsoverdracht. De afnemer meldt dit terug, bij voorkeur met het UUID van de betreffende snapshot. Er wordt een onderzoek gestart.
Tijdens het onderzoek worden de opgeslagen events nagelopen. Daaruit blijkt dat de verwerking correct is verlopen: het gevolg BelangOvergegaanNavOverdracht bevat beide partijen — Piet Pietersen en Hendrica Pietersen. Het probleem zit niet in de verwerking maar in de projectiecode — die legt bij een overdracht alleen de eerste eigenaar vast. Er is sprake van een bug in de projectielogica, niet van een fout in de registratie zelf. Het onderzoek wordt hierop bijgewerkt.
Herstel via replay
Het beheerteam fixt de bug in de projectiecode. Daarna voert het team een replay uit op de opgeslagen events: deze worden opnieuw verwerkt door de gecorrigeerde projectie.
De replay gaat event voor event door de history. Het eerste event — WozObjectMetKadastraalObjectIdGeregistreerd — levert hetzelfde resultaat op als voorheen; die snapshot was al correct. Het tweede event — BelangOvergegaanNavOverdracht — produceert nu een nieuwe, correcte snapshot: gerelateerdePartijen bevat nu beide partijen (Piet Pietersen en Hendrica Pietersen).
Het resultaat: er is precies één nieuwe snapshot toegevoegd. De registratietoestand stond al correct; de overdrachtstoestand is opgevolgd door een correcte versie. Tot slot wordt het onderzoek afgerond.
De snapshots
De ProjectieViewer hieronder toont drie snapshots. Snapshot 1 stamt uit de registratie en is ongewijzigd gebleven. Snapshot 2 is de foutieve overdrachtstoestand — het toont alleen Piet Pietersen, het resultaat van de bug. Snapshot 3 is de correcte snapshot die door de replay is geproduceerd — het toont de juiste partijen Piet Pietersen en Hendrica Pietersen.
Snapshot 2 en 3 hebben hetzelfde eventId, hetzelfde geldigheidstijdstip en hetzelfde gevolgtijdstip: ze beschrijven dezelfde snapshot op hetzelfde geldigheidsmoment, voortkomend uit hetzelfde event. Maar snapshot 3 heeft een later projectietijdstip — het is pas beschikbaar gekomen na de replay, in september 2020. Daardoor is snapshot 2 Opgevolgd en is snapshot 3 Actueel.
Cruciaal: de foutieve snapshot is niet verwijderd. Bevraag je het systeem met een projectietijdstip van vóór de replay, dan zie je nog steeds de foutieve snapshot. Dit is geen ongewenst bijproduct — het is precies de bedoeling. Het bitemporeel model maakt de foutgeschiedenis auditeerbaar: je kunt altijd reconstrueren wat het systeem op enig moment dacht te weten, ook als dat fout was. Zie ook Actueel en opgevolgd voor meer toelichting.
Dit is de architectuurles: doordat snapshots nooit worden overschreven maar opgevolgd, blijft de volledige historie van het systeem — inclusief vergissingen en correcties — onveranderd opvraagbaar. De replay herstelt de actuele snapshot zonder de geschiedenis te wissen.