Mit aktiviertem Response Streaming wird die Ausführung abgebrochen und zeigt { “isArtificialRecoveredEventItem”: true } mit „Execution stopped at this node
@sawsew467 dafür gibt es keine eingebauten Regler, Streaming bindet die Ausführung an die Live-Verbindung, sodass eine Trennung sie abbricht (jenes wiederhergestellte Item ist n8ns generischer „killed before finishing
Hallo @sawsew467,
Das isArtificialRecoveredEventItem-Merkmal ist ein Zeichen dafür, dass die Ausführung abgestürzt ist, anstatt sauber abgebrochen zu werden. Wenn sich der Browser trennt, schließt sich der TCP-Socket, und der nächste res.write()-Aufruf innerhalb von n8n’s Streaming-Chunk-Sender wirft einen EPIPE-Fehler. Das propagiert sich durch die LangChain-Callback-Kette in die Workflow-Engine, die die Ausführung im Flug zum Absturz bringt. Der Recovery-Service füllt dann diesen künstlichen Platzhalter für alle Knoten ein, die gestartet wurden, aber ihre Ausgabe nie persistiert haben.
Die SSE-Verbindung und die serverseitige Ausführung sind also in n8n’s aktueller Streaming-Implementierung architektonisch gekoppelt. Es gibt kein Config-Flag, um sie zu entkoppeln.
Deine eigentlichen Optionen:
1. Streaming auf dem AI Agent-Knoten deaktivieren: das hast du bereits probiert, aber es ist trotzdem erwähnenswert: Die Ausführung läuft serverseitig vollständig ab, ohne Trennungsrisiko, und die vollständige Antwort wird zurückgegeben, wenn der Workflow beendet ist. Der UX-Kompromiss ist real, aber die Ausführung ist zuverlässig.
2. Sofort antworten, dann abfragen: Verwende einen Webhook-Knoten, der auf “Sofort antworten” gesetzt ist. Er gibt sofort eine executionId zurück, der Workflow läuft vollständig im Hintergrund ohne an eine HTTP-Antwort gebunden (keine SSE-Verbindung, die unterbrochen werden kann), und der Client fragt GET /api/v1/executions/{id} nach dem Ergebnis ab. Langsame Tools werden immer fertig. Du verlierst das Streaming-UX, gewinnst aber deterministische Ausführung. In der Cloud hast du Spielraum beim 5-Minuten-Ausführungs-Timeout, solange dein HTTP Request nicht absurd langsam ist.
3. Queue-Mode-Worker: nur selbst gehostet, nicht in der Cloud verfügbar. Selbst dann ist unklar, ob Streaming-Schreibfehler auf dem Hauptprozess sich vollständig vom Worker-Ausführungszustand entkoppeln.
Für dein spezielles Setup ist Option 2 wahrscheinlich der bessere Weg, wenn du brauchst, dass Tools immer fertig werden. Das Polling-UX ist weniger elegant als SSE, aber viel vorhersehbarer, als darauf zu hoffen, dass der Client verbunden bleibt.
Wenn Streaming mit Trennungstoleranz kritisch ist, würde das eine Änderung erfordern, wie n8n SSE-Schreibfehler behandelt, insbesondere ohne sie zurück in die Ausführungs-Engine zu propagieren.
Beide Antworten oben haben recht, dass das eingebaute Agent Streaming von n8n die Arbeit an den Live-Request bindet, sodass eine Trennung die Ausführung abbricht und es heute keine Flag gibt, um sie zu entkoppeln. Aber du kannst trotzdem streaming UX und garantierte serverseitige Fertigstellung gleichzeitig bekommen. Der Trick ist, das Streaming nicht über n8ns Request laufen zu lassen, sondern den Stream auf einen Channel zu verschieben, den der Client unabhängig abonniert.
Eine Form, die funktioniert:
-
Behandle den Turn als dauerhaften Hintergrund-Job. Nimm PurveshGandhis Option 2 als Grundlage: der Webhook antwortet sofort mit einer Turn-ID, der Agent läuft serverseitig zu Ende ohne SSE angehängt, und der Memory Write passiert auf jeden Fall. Das allein macht die kritischen Arbeiten disconnect-sicher.
-
Hole dir Streaming zurück, indem du Chunks auf einen externen Channel schreibst, nicht auf die HTTP-Response. Während der Turn Output produziert, schreib ihn auf etwas, das der Browser unabhängig abonnieren kann: eine Supabase Realtime Row, Redis Pub/Sub, Ably, oder sogar eine partial_response Spalte, die der Client ein paar Mal pro Sekunde abfragt. Der Browser liest von diesem Channel, nie von n8ns SSE. Jetzt bricht eine Trennung nur die Lesseite ab, die Ausführung läuft weiter, und beim Neuladen abonniert der Client erneut und holt sich das Gespeicherte auf. Das ist die Haben-Beides-Antwort: die Arbeit ist an den Job gebunden, der Stream ist an den Store gebunden.
-
Wenn Token-Level Glätte wirklich wichtig ist, mach das Model Streaming in einem dünnen Streamer außerhalb von n8n (eine kleine Edge Function, die Model Tokens zum Client streamt und das finale Transkript zurück zu n8n postet für den dauerhaften Memory Write und alle Tools). n8n bleibt das System of Record, die Edge Function ist einfach das Rohr.
Noch eines, im Geiste von achamms Punkt über Side-Effecting Tools: halte jeden Side Effect, sende Emails, schreibe zu CRM, was auch immer Geld kostet, hinter dem gebilligten Turn gated und nach Turn-ID gekennzeichnet, sodass ein wiederholter oder halbfertiger Turn es nicht doppelt feuern kann. Streaming sollte nie darüber entscheiden, ob ein Side Effect passiert ist.
Also musst du dich nicht wirklich entscheiden. Binde die Ausführung an einen dauerhaften Job, binde den Stream an einen externen Channel, und die Client-Trennung spielt keine Rolle mehr.
Hallo 
Ich denke, ich verstehe das Problem — das ist ein ziemlich häufiger Spezialfall bei n8n AI Agent + Streaming, wenn die Client-Verbindung unterbricht (Browser-Aktualisierung / Wiederverbindung).
Was hier passiert, ist im Grunde:
der Stream-Lebenszyklus ist zu eng an den Execution-Kontext gekoppelt, sodass bei der Trennung des Frontends die Backend-Ausführung entweder unterbrochen wird oder falsch rehydriert wird.
Ich würde das als zwei derzeit gekoppelte Lebenszyklen betrachten:
-
Client-Streaming-Lebenszyklus
Die Browser-/Client-Verbindung möchte jetzt teilweise Token/Events. -
Server-Ausführungs-Lebenszyklus
Der Agent-Lauf muss möglicherweise beendet werden, auch wenn der Client die Verbindung trennt.
Wenn diese an dieselbe HTTP-Verbindung gebunden sind, kann eine Trennung zu einem Ausführungs-Abbruch-Signal werden. Bei langläufigen Agents würde ich sie normalerweise entkoppeln:
- Request startet einen Job und gibt eine job_id zurück;
- Server-seitiger Workflow läuft unabhängig weiter;
- Stream-Endpunkt abonniert nur Job-Events;
- Wenn der Stream getrennt wird, bleibt der Job ausgeführt;
- Client kann sich mit job_id erneut verbinden und den aktuellen Status/die Events/das Ergebnis abrufen;
- Endzustände sind success, failed, cancelled_by_user, timed_out.
Die wichtige Unterscheidung ist „Client verschwunden
Willkommen @sawsew467!
Das ist eine aktuelle architektonische Einschränkung von n8n: Wenn Streaming aktiviert ist, ist der Ausführungslebenszyklus an die Push-Verbindung gebunden, sodass eine Trennung einen Abbruch signalisiert. Es gibt derzeit keine integrierte Einstellung, um diese zu entkoppeln.
Das nächstliegende funktionsfähige Muster in n8n heute: Verwenden Sie einen regulären Webhook (ohne Streaming) als Einstiegspunkt, geben Sie sofort eine job_id an den Client über den Knoten „Respond to Webhook