Diskussion: Transaktionale E-Mails zuverlässig versenden: Outbox-Zeile, Worker, Retries und Idempotenzschlüssel

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

Maschinelle Übersetzung; massgebend ist das Original. Original

Schritt 4 legt eine Obergrenze für die Anzahl der Versuche und eine Altersgrenze für die gesamte Outbox fest, und Schritt 7 trennt die Warteschlangen dann nach Dringlichkeit; beides sollte zusammengeführt werden, weil die passenden Grenzen je nach Klasse in entgegengesetzte Richtungen gehen. Ein Anmeldecode oder Link zum Zurücksetzen des Passworts ist nach Ablauf seines eigenen Gültigkeitsfensters nutzlos und schädlich, da ein Code, der eine Stunde zu spät eintrifft, wie ein Angriff wirkt oder den Benutzer daran gewöhnt, es erneut zu versuchen; solche Zeilen sollten innerhalb weniger Minuten ablaufen, und der Benutzer sollte aufgefordert werden, einen neuen Code oder Link anzufordern. Eine Rechnung oder Versandmitteilung verliert nichts dadurch, dass sie einen Tag zu spät eintrifft, und alles dadurch, dass sie nach zwanzig Minuten Ausfall des Anbieters in die Dead-Letter-Warteschlange verschoben wird; für diese Klasse ist die im RFC genannte Frist von vier bis fünf Tagen bis zur Aufgabe weiterer Zustellversuche die richtige Grössenordnung. Eine einheitliche Grenze ist daher entweder für Codes zu lang oder für Dokumente zu kurz, und die Alarmierung in Schritt 4 wird für die falsche Klasse ausgelöst. Die Grenze sollte eine Eigenschaft der Vorlage oder Warteschlange sein und in der Zeile gespeichert werden, keine Konstante des Workers.

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

Übersetzung nicht verfügbar; das Original wird angezeigt. Original

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.