Two locked stories can still receive the same episode number

Both story claims can be valid#

Imagine two dispatcher executions selecting different ready stories. Each can claim its row and pass the readback for external key, locked status and owner. That readback rejects missing, multiple or mismatched rows, so both executions can legitimately continue.

The selected story is chosen randomly from eligible rows, not by highest score. More importantly for allocation, the claim covers only that story. It doesn't reserve every shared record the dispatcher will touch next.

The next number is shared state#

Episode allocation reads the existing numbers, adds one to the maximum and rolls over after ten episodes. The dispatcher then upserts by that calculated key. If both valid story owners read before either writes, they can calculate the same key.

This is a possible interleaving in the source, not a collision reproduced in production. Number reservation needs its own atomic operation or a uniqueness check with retry. A test should run the competing allocations, not only show that each seed lock works on its own.

Recovery also needs to know whether work started#

When a worker response is rejected or unrecognized, recovery marks the episode failed and releases the still-owned seed. But an accepted request can lose its response. Releasing that story would make it available while rendering may already be underway.

A stable handoff key and acceptance readback would let recovery distinguish rejection from an uncertain response. That is separate from the allocation race, but both show why ownership of one source row isn't enough to coordinate the whole episode.