EngineeringField note
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.
Loading Ashlr Brief
EngineeringEngineeringField note
What four database connections, held locks, and replayed delivery events showed about our newsroom—and what those checks cannot prove.
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.
Next, we held a transaction open after creating a weekly edition. A second connection tried to create the same edition with different content. Once the first committed, the application’s fresh lookup recovered the existing edition instead of replacing it. The original story snapshot and six-recipient audience stayed unchanged. An insertion conflict and a visible row are not always the same thing within one statement’s snapshot; the reproduction kit includes this case.
For delivery, one connection claimed three recipients while holding its transaction open. A second connection claimed the other three using SKIP LOCKED. The sets did not overlap, and a later claim found no remaining pending rows. We then raced duplicate delivery-event records against the send-receipt update. One event record persisted, the delivery remained delivered, and a stale completion could not downgrade it. These were synthetic database events, not emails sent through a provider.
The scope matters. This was a bounded concurrency qualification of particular SQL statements, not a throughput benchmark, an exhaustive failure test, or an independent certification. It did not call a model or email provider, measure inbox delivery, or prove that external actions happen exactly once. The script removed its synthetic records. We are publishing the harness, SQL, schema, and result summary so readers can inspect the conditions behind the claims.
Put job identity, ownership, and allowed state transitions in durable storage. Test with separate connections and deliberately held locks, then assert the final records as well as the returned responses. Keep provider acceptance separate from delivery. If a remote request times out after it may have succeeded, preserve that uncertain outcome for reconciliation instead of blindly retrying it.
Ask what an acceptance test actually demonstrates. These checks give evidence about duplicate claims and state changes in this implementation. They do not establish delivery speed, editorial accuracy, business value, or resilience under every outage. A release decision needs those separate checks and a named person responsible for unresolved outcomes.
Download the reproduction kit from the sources below and inspect the six checks. If you run it, use an empty, isolated Neon validation database and follow the included setup instructions. For your own workflow, start with one duplicate request and one late receipt, and write down the exact final state each should produce.
Source material behind this field note. Our practical implications are Ashlr’s interpretation.
Field notes explain an engineering or business practice. They are not reports of a new event. Cover artwork is illustrative.
The briefing
Multiple projects merged bridge PRs that add tests, UI fixes, and documentation. The pull requests describe changes to Phantom, Phantom Secrets, Lexicon, Locus, and ashlr-plugin.
EngineeringThe briefing
Pull requests added read-only fleet posture reports and CLI commands for denials, SLO, lag, supply and lanes. Sonar cleanups and contract fixes also landed in multiple projects.
EngineeringThe briefing
Multiple pull requests added regression tests and clarified documentation across Ashlr Stack, Locus, Ashlr MD, Lexicon, Phantom Secrets, and ashlr-plugin.