Backfill: cases that passed through bezwaar/beroep while the legal-hold control was dead

[rubenvdlinde]

Summary

BezwaarLegalHoldListener never placed a legal hold for its entire life (root cause and fix: #693). Fixing it forward does not repair the cases that passed through a bezwaar/beroep proceeding while the control was dead.

Those cases are, right now, missing the legal hold that archiving law requires, and are therefore destruction-eligible when they should be suspended.

Evidence

On the development instance, after the #693 fix was verified working:

	count
case objects	348
bezwaar proceedings	22
cases carrying a legal hold	1 (the one created by the #693 positive control)

So 21 proceedings on that instance alone produced no hold. Production numbers are unknown and need to be measured before deciding on remediation scope.

What is needed

1. Quantify — per environment, count cases that have (or ever had) an open bezwaar / objection / beroep proceeding and carry no _retention.legalHold.
2. Decide the rule for "still open" — a proceeding with a matching bezwaarDecision / appealDecision is closed, and backfilling a hold on it and immediately releasing it may be the wrong outcome. The audit history matters here: a hold that was never placed should probably not be back-dated as if it had been.
3. Backfill the still-open ones, with a reason string that makes the remediation visible rather than indistinguishable from a contemporaneous hold.
4. Check whether anything was actually destroyed while unprotected. This is the part that decides whether this is a housekeeping task or an incident.

Why not in #693

#693 is a small, provable forward fix with a live positive control. Backfill is a data-remediation programme with its own risk profile (it writes to historical records and to the retention audit trail), and it needs the production numbers from step 1 before a safe rule can be written. Bundling them would make neither reviewable.

Related

• fix(archival): place the Awb legal hold that has never once been placed #693 — the forward fix
• fix(events): resolve the schema slug listeners compare against — 3 procest listeners had never run #692 — the slug-comparison fix in the guard above this (necessary but not sufficient)
• BezwaarLifecycleListener has never run — resolveSchemaSlug() cannot return a slug #690 — the fleet-wide id-vs-slug listener bug class

[rubenvdlinde]

Findings — quantified, destruction check, and the backfill

Remediation command + full evidence in #695. Summary below.

1. The population is 1 case, not ~21

The estimate in the issue body came from raw table counts. Measured properly on the development instance it collapses, for three reasons:

	count
case rows	348
…soft-deleted	330 → 18 live
bezwaar rows	30 → 12 live
distinct cases referenced by any bezwaar	10, not 30 — many bezwaar share one case
live, existing cases among those	2
already held (the #693 control)	1
genuinely missing a hold	1

The one real case is f9013ce5-6796-4c66-82e4-f3e7a0435dd3 ("Dormer window – Lindenstraat 8") — two undecided bezwaar (In behandeling, no decision) plus an open beroep (d0413d5b). Unambiguously still in an open Awb proceeding, and it had no hold.

Of the other eight: seven are E2EZAAK-* e2e fixtures on soft-deleted cases, one (22222222-3333-…) is a dangling reference to a case that does not exist.

2. Nothing was destroyed — this is housekeeping, not an incident

This is the question the issue said decides the severity. Nothing was destroyed, and the destruction pathway has never run at all on this instance. Four checks, each paired with a positive control so an empty result cannot be a broken query:

check	result	positive control
audit action archival.destroyed	0	action='delete' → 1933, LIKE 'referential%' → 24, LIKE 'docudesk%' → 44
oc_openregister_destruction_lists	0 rows	table exists, schema verified
cases with retention.archiefnominatie='vernietigen'	0	same query shape finds the known LH-control-case hold
cases with any retention metadata	1 of 348	as above

The key structural point: DestructionExecutionJob writes its archival.destroyed audit row before deleting the object, and audit rows live in a separate table — so the audit trail is a durable witness even for hard-deleted objects. Its absence is therefore meaningful, not an artefact of the objects being gone.

Separately, findEligibleObjects() filters on retention.archiefnominatie = 'vernietigen' and retention.archiefstatus = 'nog_te_archiveren' and a past archiefactiedatum. 347 of 348 cases carry no retention metadata at all, so no case could ever have been selected — hold or no hold.

All 330 soft-deletions carry deletedBy: admin, dated 2026-06-10 → 2026-07-09, with no destruction markers. Manual/test cleanup.

3. Backfill done, with a positive control

occ procest:legal-hold:backfill (#695) — dry-run by default, idempotent, additive only, and it holds only cases with at least one OPEN proceeding (issue point 2: back-dating a hold onto a concluded proceeding would fabricate history rather than repair it). The reason string names the remediation and records that the hold was placed at repair time, not back-dated (issue point 3).

Applied: 1 case held. Positive control — read back from storage independently via SQL: legalHold.active = true, placedBy: admin, placedDate: 2026-08-01T21:31:46+00:00. Idempotency control — a second --apply wrote nothing (held = 0, already held = 2).

Three things this turned up that need their own issues

1. beroep never places a hold. BezwaarLegalHoldListener::PROCEEDING_OPENED_SCHEMAS is ['objection','bezwaar'] only. A case that goes straight to beroep gets no hold even after fix(archival): place the Awb legal hold that has never once been placed #693. The backfill command compensates; the listener does not.
2. ~311 deletions have no audit row. Only 19 of the 330 soft-deletions are audited, although the audit trail's range (2026-05-29 →) fully covers the window. An audit-completeness defect, independent of this one.
3. The four camelCase schema literals are correct, not typos. bezwaarDecision, appealDecision, hearingSession, advisoryReport all exist verbatim as schema slugs (ids 121, 120, 118, 119). More generally, 891 of 1935 schema slugs on this instance contain uppercase — "OpenRegister slugs are lower-kebab" is not true, and "fixing" those literals to kebab-case would break them.

Not done

Production numbers remain unmeasured — step 1 asked for per-environment counts and I only had the development instance. The command runs anywhere; dry-run first.

Leaving this open until production is measured and #695 merges.