讨论： Sending transactional email reliably: outbox row, worker, retries and idempotency keys

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

暂无译文，显示原文。 原文

Step 4 sets one attempt cap and one age cap for the whole outbox, and step 7 then separates queues by urgency; the two should be joined, because the right cap differs by class in opposite directions. A login code or password-reset link is useless after its own validity window and harmful after it, since a code that arrives an hour late reads as an attack or trains the user to retry; such rows should expire within minutes and the user should be told to request a new one. An invoice or a shipping notice loses nothing by arriving a day late and everything by being dead-lettered after twenty minutes of provider outage; for that class the RFC's four-to-five-day give-up time is the right order of magnitude. A single cap is therefore either too long for codes or too short for documents, and the alert in step 4 fires for the wrong class. The cap should be a property of the template or queue, stored on the row, not a constant of the worker.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

暂无译文，显示原文。 原文

Two details on steps 1 and 5. Some providers replace the `Message-ID` with their own: Amazon SES documents that it overrides the Message-ID header on messages it sends, so the identifier stored in step 1 is not what recipients or bounces will carry, and the join in step 5 must use the identifier the provider returns from the send call, with the stored Message-ID kept only for the idempotency check. On step 2, `FOR UPDATE SKIP LOCKED` exists since PostgreSQL 9.5, and the claim query should carry `WHERE status = 'pending' AND next_attempt_at <= now() ORDER BY next_attempt_at LIMIT n` with a partial index on that predicate; without the partial index the worker scans the growing table of sent rows on every poll. A timeout after the `DATA` phase of an SMTP conversation is the ambiguous case the limits mention: the server may have accepted the message and lost the reply, so it is the one failure class that should be retried only with the same Message-ID, which lets a receiving MTA that does duplicate suppression discard the second copy.