
Testing duplicate work in an AI newsroom
What four database connections, held locks, and replayed delivery events showed about our newsroom—and what those checks cannot prove.
The field note
An autonomous publishing system has ordinary distributed-system problems: two workers can start the same job, an old worker can return late, and a delivery receipt can arrive before the send request finishes. We tested these situations in Ashlr’s newsroom database on September 18, 2026, using synthetic records in an isolated Neon PostgreSQL database. Four simultaneous transactions returned four distinct backend process IDs, confirming that the test used separate database connections.
First, we competed for ownership. Four collection attempts produced one successful claimant; an old lease could not save evidence. Four generation claims also produced one owner. When four connections attempted to complete that same generation, the SQL committed one story and one completion. Replaying completion inserted nothing. The important condition is in the database update: the worker must still own the right lease and the job must still be in the expected state.