A contested byline must not kill the feed that carried it

[ralyodio]

The harm

Two Substack feeds have been failing every crawl for hours:

21:39:59  error feed  zinotrust.substack.com could not be crawled — UNIQUE constraint failed: authors.slug
21:40:00  error feed  The Modern Selling Podcast could not be crawled — UNIQUE constraint failed: authors.slug

The cost is wildly out of proportion to the cause. Because the author insert rides in the crawl's own write transaction, losing a slug race takes the whole crawl with it — the feed is recorded uncrawlable and walks up the backoff ladder. Ten consecutive failures marks a feed dead. Over a byline.

The race

claimAuthorSlug reads the slugs already taken, and this insert runs later. Two crawls naming the same author can both pick jane-doe before either commits.

The existing on conflict (identity_key) upsert does not catch it, because the colliding rows are two different people who happen to share a display name.

It predates the write queue — it was failing crawls hours before Redis was switched on.

The fix

SQLite has allowed multiple upsert clauses since 3.35 and libSQL honours them (verified against a real database before relying on it), so this is one line:

on conflict (identity_key) do update set ... where ...
on conflict (slug) do nothing

Doing nothing is the right answer, not merely the safe one. The loser of the race is deferred, not lost: by the next crawl the slug is taken, so claimAuthorSlug picks the next free one and the credit lands then. A byline missing for one cycle is a far smaller thing than a feed marked dead.

upsertAuthor takes the other path into this table from the enrichment pass and had the same hole; closed the same way.

Tests

The tests pin the whole shape, including that the guard does not swallow the ordinary path — a matching identity_key must still update, and only a different identity colliding on slug is a no-op. Verified non-vacuous: removing the clause fails them.

Full suite: 1,157 tests, 0 failures.

Note

Feeds already pushed up the backoff ladder by this will recover on their own once the fix deploys, but their error_count stays elevated until a successful crawl resets it. Say the word if you want those reset explicitly, as I did for the 429s earlier.