A same-ID/same-digest submit arriving while the first is still in flight
was refused. Nothing is wrong with it: it is one request that reached the
store twice, and the durable path cannot answer it because there is no
receipt yet and no terminal entry to read.
The follower reserves nothing and sequences nothing. `accept` removes its
waiter and moves its completion onto the leader's, so from there it is
answered by whatever resolves the leader and by nothing else -- one frame,
one sequence, two callers answered. The tests assert that by requiring the
follower's `repo_sequence` to equal the leader's, because a second
sequence would mean a second frame for one operation.
Followers live on the leader's `Waiter` rather than in a table keyed by
operation, so a follower cannot outlive the request it follows: every path
that resolves a waiter drops it and takes its followers with it. All eight
completion sites now go through `Waiter::resolve`, which answers the
followers and then the leader with one outcome.
That centralization is the point rather than tidiness. Only one of those
sites is the happy path; the rest are pre-append refusal, poison drain,
deadline removal, and panic unwind. A follower any of them forgot would
not fail -- it would hang, with neither receipt nor error, which is the
outcome hardest to notice and hardest to diagnose. So the case worth
proving is a leader taken down inside the poison window, and
`a_follower_is_answered_when_its_leader_is_poisoned` arms one.
The two coalescing tests hold the fault serial even though only one arms a
failpoint. The registry is a one-shot global, and without it the arming
test fired inside its sibling's engine -- a real interference that made
both pass alone and fail together.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JGdH5V43XWnj1PdHqiPktQ
Levi Neuwirth
df2e22a3b0