Refuse an append the record moved under, so a fenced run loses nothing

[andreisavu]

PR 13b of the fifteen SPLIT_PLAN.md on #48, the second half of the plan's PR 13. Branches from main after #69. One commit.

The one idea

A run paused with a write in flight comes back to a name another run has taken. Its write lands past the fence, void, and the run acknowledges it. That was the one loss the fence allowed, and split.test.ts pinned it as the last one.

• A session may offer appendAfter. The log hands it the position its read left: the entry lands next to that position, or the storage writes nothing and says the record moved. A run fenced while its write waited is refused before it acknowledges.
• The refusal is definite, not a doubt. Nothing landed, so a client may deliver again under the same key. The history checker holds a refused delivery to the record zero times, which is stricter than the "at most once" it allows a write in doubt.
• A storage that cannot promise it does not offer it, and the log appends the way it always did. The fence still voids what such a storage takes.

How SQLite promises it

One statement, because the assertion and the seq are the same fact:

INSERT INTO entries (...) SELECT ?, ?, ...
WHERE (SELECT COALESCE(MAX(seq), 0) FROM entries WHERE session = ?) = ?

The insert asserts the record's last seq and takes the next one. A writer the record moved under inserts nothing. Sql.run reports no rows, so a read back says which happened — and that is why the entry's id is its own and never the position. Two runs that expect one seq derive one id, and the read back could not then tell one run's entry from the other's. That bug was live in my first draft: the paused host's refused write "succeeded", because the read back found the other run's entry sitting at the id it had derived.

What readSince turned out to be

The plan paired appendAfter with readSince, "a read from a cursor that sees every writer, which SQLite indexes". The SQLite storage's findEntries already is that: WHERE seq > ? against the primary key. The plan's point was that Pi's repositories scan, and that is a cost, not a correctness gap. Nothing to build.

The tests that pin it

split.test.ts now runs the one split scenario on both storages and holds each to what it promises:

• on memory, the paused host loses the write it held — the two violations the fence allows, unchanged;
• on sqlite, violations() is empty and the held delivery is fail, not ok.

Two test wrappers had to learn the new append, and that is worth a reviewer's eye: gatedOpener and tappedOpener proxy appendCustomEntry, so a SQLite write would have slipped past the gate that makes the split, and past the tap that counts writes for the crash sweep. Both now take appendAfter too, and only when the session actually has it — a proxy that offers a method the target lacks makes fenced() say yes and the call explode.

What this closes

planning/backlog.md item 35, fully. What still stands is recorded there: a storage that cannot refuse still loses the one held write, and Pi's JSONL storage reads its own memory so the fence does not reach it at all.

Checks

pnpm format && pnpm check is green, 421 tests. pnpm chaos is green, 850 tests.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SJjjR3S6iwqEbDXsRDJgiq

---

Generated by Claude Code