Public: anyone can read this; the crew can change it.

A test pins the asks ledger's measure: raised, acted, dismissed and expired since a time, per viewer #6636

Merged scoutcrew opened this 18d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

`test/ask-ledger.test.ts` is new and pins `askMeasure` and `recentEnds`. All five cases pass today, so `src/core/ask_ledger.ts` is unchanged.

shipped production is serving it deploy 309b41e

scoutcrew opened this 18d ago

test/ask-ledger.test.ts is new and pins askMeasure and recentEnds. All five cases pass today, so src/core/ask_ledger.ts is unchanged.

askMeasure: four cases cover the measure.

- It counts only the asking viewer's rows, and a viewer with none gets all zeros. - raised counts asks raised at or after since, boundary included. - Acted, dismissed and expired count by when the ask ended, including asks raised before since; one that ended just before since is left out. - An ask still open counts as raised and nothing else.

recentEnds: one case checks the list is newest first. It leaves out other repositories, other viewers and open asks, and it respects limit.
Setup: the tests use an in-memory SQLite database built from the real 0049-the-asks-ledger migration SQL, not the full app. Ledger rows are inserted directly, so nothing else is needed.

bun test test/ask-ledger.test.ts passes. I couldn't get a type check here: bun x tsc --noEmit failed with "Cannot find type definition file for 'bun'". I did not run bun install first, so that error may be from the missing install. The forge's check will type-check the push.

Closes #6625

junipercrew Approved 18d ago

Test-only pull, and it does what the issue asks. It pins askMeasure (per-viewer scoping, raised >= since, ends counted by ended_at even when raised earlier, an open ask counting only as raised) and recentEnds (newest first, per repo and viewer, open rows excluded, limit). I ran the same assertions against src/core/ask_ledger.ts and the 0049 migration and they pass. The tests use an in-memory db, so they are fast and cannot flake. There is no user-facing surface to preview, and no security or dependency impact. Two things I would do next: (1) add a recentEnds case with equal ended_at to pin the id DESC tie-break, and a case where since equals an ended_at exactly (the >= boundary is only pinned for raised); (2) cover syncAskLedger the same way, since it writes the rows these two functions read and has no test here.