Resiliente Warteschlange: Ein Infrastrukturausfall beendet die Aufgabe nicht mehr

Produktions-FixesWiedereinreihung bei Infrastrukturausfall, Nicht-als-abgebrochen-Markieren-beim-Neustart, zwei Queries, die PostgreSQL immer abgelehnt hat, Klassen-Guard für Silent Failures und Warmup von E-Mail-Threads ohne vorformulierte Antwort.

Warum das eine Produktmeldung ist

Die 15 Spezialisten von ADRI hängen von OllamaTasker + Node-Balancer + FastAPI ab. Wenn ein Worker um 3 Uhr nachts neu startet, sollte der Vertrieb nicht „du hast die Aufgabe abgebrochen“ sehen. Er sollte Wiederholung oder Wiedereinreihung sehen – und der Silent-Failure-Hunter sollte nicht über den Ausfall lügen.

• Lange Aufgaben (OSINT, Code, Vision) überstehen Aussetzer
• Abrechnung und tools_used werden erst am tatsächlichen Ende des Turns abgeschlossen
• Operatoren sehen den ehrlichen Grund des Ausfalls

Warteschlangen-Architektur in deinem On-Prem

Was fehlschlägt, wenn die Warteschlange nicht resilient ist

In einer Multi-Agenten-Architektur (Laravel-Tasker + Node-Balancer + Python-API) ist ein Worker-Neustart um 3:00 Uhr kein „seltsamer Bug“: Er ist Alltag. Wenn die Aufgabe als abgebrochen markiert wird oder verschwindet, verliert der Nutzer Vertrauen, und die Abrechnung gerät aus dem Takt (offener Turn, Tools nur halb abgerechnet).

• Wiedereinreihung: Die Arbeitseinheit kehrt mit derselben Session-/Workspace-ID in die Warteschlange zurück.
• Idempotenz: Schreib-Tools duplizieren keine Effekte, wenn der Schritt wiederholt wird.
• Ehrlicher Abschluss: Tokens und tools_used werden erst am tatsächlichen Ende des Turns konsolidiert.

Betriebliche Signale

Operatoren müssen sehen, warum wiederholt wurde (LLM-Timeout, OOM, Deploy), nicht einen „generischen Fehler“. Das erlaubt es, einen Modellfehler von einem Infrastrukturausfall zu unterscheiden.

Häufig gestellte Fragen

Verwandt: ADRI-Agenten · Architektur in deiner Infrastruktur.

• Warteschlangen
• Resilienz
• OllamaTasker
• SRE