Skip to main content

The DB lifecycle-status enum stays coarse; new granularity lives in the derived display layer

SUPERSEDED by ADR-0012 (2026-07-09). Pran's #950 replaces the coarse DB enum with the rich canonical vocabulary (new Order.status literals + order_status_literals migration). The enum does NOT stay coarse. The "consolidate scattered literals into ORDER_STATUS_SETS" follow-up below is itself superseded by #950's states.ts evaluators on the new vocabulary — see ADR-0013. Read ADR-0012 first.

The persisted Order.status 8-value enum (pending, submitted, accepted, partially_accepted, declined, cancelled, lapsed, settled) is load-bearing infrastructure. It is referenced by hand-maintained, un-synchronized status-string literals with no shared constant across:

  • netting-candidate selection — netting/reversal.ts:81 NON_CONTRIBUTING_STATUSES and netting/marketExposureLifecycle.ts:112 raw-SQL status IN (...) (two different hand-kept lists);
  • the order-sync poll query — jobs/orderSyncJob.ts:191/1586/4439 (three duplicated inline copies);
  • settlement candidate-selection / idempotency — services/settlement.ts;
  • the FE three-bucket My-Bets fetch — strykr-fe/.../hooks/useMyBets.ts (a new value makes an order vanish from every bucket).

Adding a new value to this enum risks silently stuck orders (never polled → never settled) or vanished bets (FE), and none of the sites fails loudly. Therefore all new user-facing status granularity is added ONLY in the read-time Display Status layer (ADR-0001); the DB enum is left unchanged. The netting math core (nettingEngine.ts) is already status-agnostic, so this keeps the whole money path insulated from display concerns.

Consequences​

  • Follow-up (separate change, not this one): consolidate the scattered literals into a single ORDER_STATUS_SETS source of truth on each side of the stack — a latent maintenance/financial risk independent of the display-status work.