kimi.md: Retry-Haertung + Race-Fix der Mail-API dokumentiert

2026-10-07 19:55:25 +02:00
parent 0ebdb640b1
commit 2b93507abb
1 changed files with 1 additions and 0 deletions
@@ -893,4 +893,5 @@ Zustellung an axel@hocks.eu status=sent, Test-Ticket bereinigt.
 - Bekannte Lücke (nicht behoben): Mail-Versand aus der API ist fire-and-forget ohne Retry bei RCPT-Zeit-Fehlern (mail-api fängt nur OSError; smtplib.SMTPRecipientsRefused → Mail geht verloren, 451/550 beim Relay). Beim Test mit kaputter virtual-Map aufgetreten.
 - HINWEIS: sfg-mail (Schulportal, /opt/sfg-mail/postfix) hat denselben Aufbau (sender_canonical → noreply@hocks.eu) — dort ggf. denselben Loop prüfen/nachrüsten. Queue aktuell leer.
 - Erledigt: sfg-postfix identisch nachgerüstet — `nichtantworten@fv-sfg.de → axel@hocks.eu` (lmdb-Virtual-Alias). Kein Loop-Verkehr in 72 h sichtbar, SMTP-EHLO von sfg-mail-api ok, Queue leer, 45 s Beobachtung ohne Bounces. Env/Netz/Restart-Policy des Containers übernommen.
 - Retry-Härtung mp-mail-api (`/opt/mp-mail/api/server.py`, nur Server): `/send` legt bei JEDEM Fehler (statt nur OSError) in die Outbox; Worker loggt VERSANDT OK / Fehlversuche / ALARM nach 10 Versuchen (sichtbar in docker logs); erfolgreiche und endgültig gescheiterte Einträge werden entfernt. **Race-Fix:** Outbox-Laden/Speichern unter Lock — zuvor rasten 2 parallele /send-Aufrufe (Registrierung sendet 2 Verwaltungs-Mails gleichzeitig) zu korruptem outbox.json mit Eintragverlust (real aufgetreten 17:38, „Extra data"). Korrupte Datei archiviert (`/data/outbox.json.corrupt-20261007`). Retry-Mechanik isoliert getestet (Fehler→Outbox→Zähler→Erfolg-Entfernung: alle Schritte bestanden); Live-Sofortversand weiterhin ok (status=sent). sfg-Mail-API hat denselben Mechanismus bereits eingebaut — dort nichts zu tun.