This newsletter's sender keeps one Postgres row per issue, and each deploy asks that row whether the latest issue already went out. Until yesterday the guard read the row and then wrote 'sending' as two separate statements. A regression test firing two simultaneous requests proved both cleared the read before either wrote, and both went on to load the subscriber list. The row is unique by slug and the finish step overwrites it, so one row reading 'sent' is equally consistent with one sender and with two.
ON CONFLICT (slug) DO UPDATE
SET status = 'sending', attempted = 0, sent = 0, failed = 0, started_at = NOW()
WHERE newsletter_issue_email_sends.status = 'failed'
RETURNING statusThe losing request is skipped with the reason sendInProgress and attempted 0. Keeping 'failed' in that WHERE clause is deliberate: a bare insert-if-missing would leave a partially failed send unretryable, trading a duplicate for a silent gap.
| Clean signal | It cannot prove | What settles it |
|---|---|---|
| Status row reads 'sent' | that exactly one sender ran | the statement granting the row: can two callers both win it? |
| Test suite is green | that an unwritten case is safe | run the new test against the old code and watch it go red |
| No duplicate complaints | that no duplicate arrived | the provider's per-recipient log for that issue |
| Archive has no gaps | that each issue shipped on the date it shows | each issue's date against the commit that added it |