harden: supersede ALL prior established reconciliations per dimension + UNIQUE guard #58

New issue

Closed

opened 2026-07-04 12:11:55 +00:00 by momsse · 1 comment

momsse commented

2026-07-04 12:11:55 +00:00

Owner

Migré depuis viziertronic/octant#124 — ouvert le 2026-06-27 par @momsse.

The supersede saga (both the transaction-side and the new document-side, #53) looks up a single prior established reconciliation per dimension (SqlSchema.findOneOption + ORDER BY reconciliation_id ASC; Array.findFirst in the in-memory port). If a document/transaction ever holds 2+ established reconciliations at establishment time — concurrent establishes racing the async saga, or legacy/backfill data — only one prior is superseded and the rest stay established, re-opening the double-count.

#53 fixes the reported single-prior scenario; this tracks the deeper invariant:

supersede every prior established reconciliation per dimension (findAll + iterate, for both the transaction and document dimensions);
align the in-memory port to the Postgres ordering (reconciliation_id ASC) so tests and production pick the same rows;
add a write-side UNIQUE primitive (inline projection + constraint on the established document/transaction) so "at most one established per dimension" is enforced structurally rather than only by the eventually-consistent saga.

Surfaced in the #53 local review.

> _Migré depuis [viziertronic/octant#124](https://github.com/viziertronic/octant/issues/124) — ouvert le 2026-06-27 par @momsse._ The supersede saga (both the transaction-side and the new document-side, #53) looks up a **single** prior established reconciliation per dimension (`SqlSchema.findOneOption` + `ORDER BY reconciliation_id ASC`; `Array.findFirst` in the in-memory port). If a document/transaction ever holds **2+** established reconciliations at establishment time — concurrent establishes racing the async saga, or legacy/backfill data — only one prior is superseded and the rest stay `established`, re-opening the double-count. #53 fixes the reported single-prior scenario; this tracks the deeper invariant: - supersede **every** prior established reconciliation per dimension (`findAll` + iterate, for both the transaction and document dimensions); - align the in-memory port to the Postgres ordering (`reconciliation_id ASC`) so tests and production pick the same rows; - add a write-side **UNIQUE** primitive (inline projection + constraint on the established document/transaction) so "at most one established per dimension" is enforced structurally rather than only by the eventually-consistent saga. Surfaced in the #53 local review.

momsse commented

2026-07-04 12:11:55 +00:00

Author

Owner

@momsse — 2026-06-27 (commentaire migré) :

Add to scope: when reworking the in-memory ReconciliationsQuery lookups for multi-prior, also (a) extract the shared Ref.get → filter(isEstablishedExcluding) → findFirst structure into one private helper, and (b) sort the filtered slice by reconciliationId so the in-memory ordering matches the Postgres ORDER BY reconciliation_id ASC. Surfaced again in the #125 review.

> _@momsse — 2026-06-27 (commentaire migré) :_ Add to scope: when reworking the in-memory `ReconciliationsQuery` lookups for multi-prior, also (a) extract the shared `Ref.get → filter(isEstablishedExcluding) → findFirst` structure into one private helper, and (b) sort the filtered slice by `reconciliationId` so the in-memory ordering matches the Postgres `ORDER BY reconciliation_id ASC`. Surfaced again in the #125 review.

momsse closed this issue

2026-07-04 12:11:56 +00:00

momsse referenced this issue

2026-07-04 12:18:59 +00:00

harden: bound BankAccount dedup state + snapshot-safe codec #59

momsse referenced this issue

2026-07-04 12:18:59 +00:00

perf/harden: reconcile-hourly loads unbounded read tables + double-writes per new reconciliation #60