How HoldSend is tested
HoldSend makes two promises: nothing written is ever lost, and nothing is ever published twice. These are the tests that hold it to them.
Never twice, never lost
packages/server/test/never-twice-never-lost.test.ts runs the real client (Outbox) against the real server flow (handleIdempotent) over a simulated network, with histories generated by fast-check:
- people writing, cancelling, and up to three senders flushing alone or at the same time (double taps, several tabs);
- requests lost on the way, answers lost after the server did the work, requests delivered twice, server errors, writes failing mid-transaction;
- an app killed in the middle of a send, leaving its claim behind;
- device clocks ahead of or behind the server, and time passing;
- storage that answers at once, and storage that pauses at every call so senders interleave.
After each history the network becomes reliable, dead claims expire, people press "Try again" on anything stuck, and the outbox is flushed until empty. Then it checks that every item that was not cancelled exists on the server exactly once, that cancelled items exist zero times, that nothing exists that no one wrote, and that each stored written time is the time it was written (or arrival, when the device clock ran ahead) and never after arrival.
Run it with more cases:
npm run test:soak # 3000 histories per property
HOLDSEND_RUNS=20000 npx vitest run never-twice
The suite is checked against broken code
A test that passes against broken code proves nothing. Each of these deliberate bugs was introduced and the suite failed on it, then the bug was removed:
| Deliberate bug | Caught by |
|---|---|
| The client uses a new key on every retry | never-twice suite (shrunk to: one write, one lost request) |
| The server forgets completed keys | never-twice suite (an item created twice) |
| Cancel allowed after an attempt started | never-twice suite (a cancelled item created) |
| Completion not guarded by the claim token (Postgres) | store contract suite |
| IndexedDB read and write in separate transactions | web concurrency test |
| React Native stores not sharing one update chain | React Native concurrency test |
| Items queued after a live attempt can be cancelled | never-twice suite (a cancelled item created) |
| IndexedDB connection not reopened after the browser closes it | web reconnection test |
| Background sync reports success while items still wait | web background-sync test |
Real Postgres
packages/server/test/real-postgres.test.ts runs in CI against a Postgres 16 server with a pool of ten connections: sixty concurrent copies of one request must create one row, and twenty concurrent takeovers of a stale claim must produce one winner while the old owner's commit fails. Locally it runs when HOLDSEND_PG_URL is set.
Audit regressions
packages/*/test/audit-regressions.test.ts hold one test per finding of the first independent audit. Each was run against the code before its fix and failed there.
Other suites
- Store contract (
packages/server/test/store-contract.test.ts): the same rules against the in-memory store and a real Postgres engine (PGlite), including thirty concurrent copies of one request creating one row. - Platform stores: IndexedDB through a spec-following implementation, two "tabs" on one database; AsyncStorage and MMKV fakes that yield like the real bridge.
- Core rules: claims, settling, cancel, approve, retry and discard as pure functions.