- Shipped
- September 23, 2026 at 1:27 AM UTC
- Author
- Kamo
- Commit
- 86293d0
/leads/credits (GET /api/security/credits/manage) counted the lead pool once per allotment row — ~8 s apiece against one org's 796k-lead pool — then once more grouped (~11 s), counted each row's credit balance, and did a member lookup plus a count per eligible member for "accepted today". /leads/available and the nav indicator (/available-summary, re-fired by four realtime events) issued five or six queries per vendor product: pool count, balance count, allotment lookup, spent-today and accepted-today. Both now read a fixed number of statements, whatever the size of the grid: - the pool per (market, product) for the whole org from the pool ledger (one read); - every row's balance from the credit-balance ledger (one read); - "accepted today" for every eligible member in one query from the earliest member's local midnight, each spend kept only if it falls after ITS member's own midnight — the same window the Max Daily Spend cap enforces; - the member's allotments once, resolved per product in memory **************** and spent/accepted today grouped by product. Per product only the licensing probe remains, and it is skipped when the pool is empty. The ledgers themselves: create_lead_ledgers.sql (tables, journal triggers on leads / lead_credits, the partial pool index ix_leads_assignable_pool, a (member, date_spent) index for the daily-cap counts) and backfill_lead_ledgers.sql — both applied to the live database on 2026-09-22 and verified equal to a full recount. kamo-shared-library ae437ebc moved the repository reads onto them; DaemonService folds and recounts. Why a journal and not a counter column: see the header of create_lead_ledgers.sql. Tests: LeadCreditManageLedgerTest and LeadAvailableLedgerTest pin the figures, the per-member midnight filter and the absence of any per-row query (both mutation-checked: dropping the midnight filter or restoring a per-product pool count turns them red).