atomic-design-poc/docs/project/archive/refactor-backlog-setup/refactor-backlog/implementation/rb-20.md

RB-20 — route ApplicationsStore.cancel / AdminCasesStore.delete through runSubmit, surface the error

Status: implemented · 2026-08-27 · Source finding: 04-cqrs-light.md CQ-002 · 00-baseline.md BL-007 · 99-backlog.md RB-20 · SIGN-OFF: consolidation approved 2026-08-27, HALT lifted

What was wrong

ApplicationsStore.cancel and AdminCasesStore.delete both owned an optimistic write next to their RemoteData read, and both reached ApplicationsAdapter directly instead of going through runSubmit (the fold + Idempotency-Key mint every other mutation in the repo uses, including createSubmitChangeRequest in the same folder). The failure path was a bare catch { this.state.set(before); }: a failed cancel or delete rolled the row back, but the user saw no message at all — no ActionState, no ProblemDetails detail, nothing. The Idempotency-Key on the wire was also a fresh UUID per HTTP attempt (minted by api-client.provider.ts's default), not the per-logical-submit key runSubmit promises — harmless today only because Program.cs happens to ignore the header outside the Submit helper (CQ-005's note).

What changed

CQ-002's option (a) — the smallest fix, applied identically to both stores. No new command factory, no adapter split (CQ-002's own "Not filed" note reserves that split for option (b), which this ticket does not take).

File	Change
apps/ssp/src/app/registratie/application/applications.store.ts	cancel now calls runSubmit(() => this.adapter.cancel(id), SUBMIT_FAILED); added a private error signal, exposed read-only as lastError. On failure: roll back AND this.error.set(r.error). On the next attempt, the error is cleared before the call so a stale message never survives a fresh action.
apps/ssp/src/app/registratie/application/applications.store.spec.ts (new)	4 specs: load+parse, optimistic cancel, roll-back-and-surface-error on failure, stale-error-clears-on-next-attempt. No spec file existed for this store before RB-20.
apps/ssp/src/app/registratie/application/admin-cases.store.ts	Same shape as applications.store.ts: delete through runSubmit, error/lastError signal pair.
apps/ssp/src/app/registratie/application/admin-cases.store.spec.ts	Existing "rolls back … when the delete fails" spec extended to also assert lastError(); one new stale-error-clears spec added.
apps/ssp/src/app/registratie/ui/dashboard.page.ts	One @if (cancelError(); as err) { <app-alert type="error">{{ err }}</app-alert> } above the aanvragen list, mirroring brief.page.ts's lastError rendering. cancelError is a computed(() => this.apps.lastError()).
apps/ssp/src/app/registratie/ui/admin-cases.page.ts	Same @if (store.lastError(); as err) { <app-alert type="error">{{ err }}</app-alert> }, placed above <app-async> inside the canManage() branch (store was already protected, so no new exposure needed).

applications.adapter.ts (cancel, deleteAny) is unchanged — the fix is entirely in the two stores, which now wrap the existing thin adapter calls in runSubmit at the call site, exactly as createSubmitChangeRequest wraps ChangeRequestAdapter.changeRequest. The adapter methods still return a bare Promise<void>; runSubmit is what folds that into a Result.

Neither UI change introduces a new user-facing string: the rendered text is either the existing SUBMIT_FAILED constant (@@submit.failed, already translated in messages.en.xlf since RB-17) or, when the backend sends one, a ProblemDetails detail string carried verbatim from the server — never a new $localize id. messages.en.xlf did not need a new <target>.

The tests, and their red failures

Both specs assert store.lastError() after a rejected adapter call, which only the fix can satisfy — the old bare catch { this.state.set(before) } never touched an error signal, so lastError() stayed null forever.

Verified red without the fix (an Edit undo of the store method, not git checkout, so the rest of the change — imports, the other store, the UI, the specs — stayed in place):

• applications.store.ts: reverted cancel to try { await this.adapter.cancel(id); } catch { this.state.set(before); }. Reran ng test ssp --include applications.store.spec.ts: 2 of 4 failed — rolls back the removal and surfaces the error when the cancel fails and clears a stale error on the next cancel attempt, both with AssertionError: expected null to be 'Het indienen is niet gelukt. Probeer het later opnieuw.'. The other two specs (load, optimistic-cancel-success) stayed green, as expected — they don't touch the error path. Re-applied the fix (Edit back to the runSubmit version); reran: 4/4 green.
• admin-cases.store.ts: same procedure on delete. Reran ng test ssp --include admin-cases.store.spec.ts: 2 of 4 failed with the identical expected null to be '...' shape. Reverted to the fix; reran: 4/4 green.

Judgement calls

• Signal naming: private backing field error, public readonly lastError — matching the name BriefStore/OrgTemplateStore already expose for exactly this purpose (CQ-002's own citation), rather than inventing a new name per store.
• Error cleared at the start of each write, not only on success, so a second cancel/delete attempt after a failure doesn't leave a stale banner up if the retry itself is still in flight. Covered by the "clears a stale error on the next attempt" spec in each file.
• No ActionState/SaveState pair (the fuller shape BriefStore uses for busy-state and save-state together) — CQ-002 explicitly scoped option (a) to "one error signal", and neither store needs a busy indicator: the row already disappears optimistically the instant the click happens, so there is nothing for a spinner to cover.
• UI placement: one alert per page, above the list the mutated row belongs to, using the same @if (x(); as err) { <app-alert type="error">{{ err }}</app-alert> } shape as brief.page.ts — composition of an existing atom, no new building block (CLAUDE.md §2).
• applications.adapter.ts left untouched, on purpose — CQ-002's "Not filed" note ties the read/write file split to option (b) only; taking option (a) means this ticket changes no adapter code at all, matching the ticket's own framing ("(a) touches 2 files plus a UI line each").

Ticket accuracy

CQ-002's description matched the code as found: both stores' cancel/delete reached the adapter directly with a bare catch { this.state.set(before); }, no Result, no error channel — no discrepancy to flag.

Residuals (not this ticket)

• RB-18 (key IdempotencyStore on {SubjectId}:{idemKey}) is unaffected: cancel/delete now mint a key through runSubmit like every other mutation, so it lands on the same write-only call set RB-18 already targets.
• RB-21 (extract createDraftSync's read half) is a separate CQRS-light finding in the same context, untouched by this ticket.

Verification

npm run ci (foreground, timeout: 600000): green — ✔ local CI passed. Lint, typecheck, dep:check (342 + 226 modules, 0 violations), format:check, check:tokens, check:seam, tests (ssp 263/263 — 5 more than the pre-RB-20 258, from the new/extended specs above — behandelportal 37/37, shared 138/138, beheer 23/23), ng build --localize (both apps), npm audit (0 vulnerabilities), backend dotnet format --verify-no-changes + dotnet test --filter "Category!=Integration" (260/260 — this filter is what keeps the known OpenZaakIntegrationTests.Admin_cases_… container-dependent test, which needs a live OpenZaak container, out of npm run ci entirely; it is a standing caveat, not introduced by this change, and not exercised by this run), backend dependency audit (0 vulnerable packages), gen:snippets / gen:behaviour-spec / gen:api drift checks all clean once the regenerated behaviour-spec.mdx was staged alongside the code (the local gate's git diff --exit-code compares the working tree to the index, so it is clean once the file is staged — this is the documented pre-commit behaviour from RB-17's note, not a defect).