Schnittstellen, API & Automationen › Mail-Outbox-Worker (Cron)
Mail-Outbox-Worker (Cron)
AutomationLive✓ Geprüft am Sat Sep 05 2026 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)Versendet zuverlässig Mails, die aus irgendeinem Grund nicht sofort rausgegangen sind — eine Warteschlange, die es immer wieder versucht statt eine Mail stillschweigend zu verlieren.
Bild folgt
Jede fehlgeschlagene ausgehende Mail landet zunächst in einer Warteschlange statt direkt verloren zu gehen. Dieser Lauf holt sich alle 30 Sekunden bis zu zehn fällige Einträge, versucht jeden erneut zu versenden und plant bei einem weiteren Fehlschlag den nächsten Versuch mit wachsendem Abstand ein — bis zu acht Versuche insgesamt. Ein Eintrag, den ein Lauf mitten in der Bearbeitung verliert (etwa weil der Prozess abstürzt), würde sonst für immer als „in Bearbeitung" hängen bleiben; ein eingebauter Aufräummechanismus setzt solche Einträge nach fünf Minuten automatisch zurück, damit sie erneut versucht werden. Scheitert ein Eintrag endgültig nach allen Versuchen, wird — je nach Art des Eintrags — der zugehörige Vorgang als fehlgeschlagen markiert und im Aktivitätsprotokoll festgehalten, statt einfach zu verschwinden.
- Mails kommen mit spürbarer Verzögerung an → normal, solange die Warteschlange kurz ist; erst ein dauerhafter Rückstau (siehe die Herzschlag-Warnung der Tagesabschluss-Erinnerung) deutet auf einen Ausfall dieses Laufs hin.
- Ein Eintrag bleibt dauerhaft „in Bearbeitung" → sollte sich nach spätestens fünf Minuten von selbst lösen; hält es länger an, läuft dieser Lauf vermutlich gar nicht mehr.
- app/api/cron/outbox-worker/route.ts
- lib/outbox/worker.ts
- docs/DEPLOYMENT.md
| zeitplan | alle 30 Sekunden (docs/DEPLOYMENT.md:112-120: ein minütlicher Cron ruft ihn zweimal mit 30s Pause dazwischen auf) |
|---|---|
| ausloeser | fällige Warteschlangen-Einträge (max. 10 je Lauf); zusätzlich ein Reaper, der seit über 5 Minuten hängende Einträge zurücksetzt |
| benachrichtigt | niemanden direkt — bei endgültigem Fehlschlag (8 Versuche) wird der zugehörige Vorgang (z.B. ein Dokument) als fehlgeschlagen markiert und im Aktivitätsprotokoll festgehalten |
| beruehrt | Ausgehende Mails/Nachrichten (integration_outbox-Tabelle) |
| vault_filter | n/a — die Warteschlange hat keinen Auftragsbezug, der gefiltert werden müsste |
| ja — das IST der Mailversand-Mechanismus |
Beleg: app/api/cron/outbox-worker/route.ts — ruft runOutboxWorker() (lib/outbox/worker.ts); docs/DEPLOYMENT.md:112-120 zeigt konkretes /etc/cron.d-Beispiel dafuer
Tiefer fragen
Kontext aus dem KFZ-Bozo-Handbuch
Knoten: auto-outbox-worker (Automation · Schnittstellen, API & Automationen · live · geprüft Sat Sep 05 2026 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit) @ 0f0406a1)
Kurz: Versendet zuverlässig Mails, die aus irgendeinem Grund nicht sofort rausgegangen sind — eine Warteschlange, die es immer wieder versucht statt eine Mail stillschweigend zu verlieren.
Lies zuerst (Lesebereich, nicht der ganze Baum):
app/api/cron/outbox-worker/route.ts
lib/outbox/worker.ts
docs/DEPLOYMENT.md
Hängt zusammen mit:
data-kommunikation (lib/db/schema.ts) · sec-cron-auth (app/api/cron)
Offene Fragen der Seite:
keine
Hausregel 2: Vault-Daten sind für diese Session unsichtbar; Quellpfade auf Vault-Code sind keine Freigabe.
Frage: {{DEINE FRAGE}}
Antworte nur mit Belegen: nenne Datei und Zeile für jede Aussage.
Wenn die Quellen die Frage nicht beantworten, sag das und nenne, was du zusätzlich lesen müsstest.
Weicht die Seite vom Code ab, schlage den Seiten-Patch vor (wiki/seiten/schnittstellen-automation/auto-outbox-worker.md).