Hallo,
Ich habe wiederholte „Verbindung unterbrochen
Willkommen in der n8n Community @Raul_Martin_Acebes
Ich würde zunächst die Browser-“Offline”-Meldung von der Workflow-Ausführung selbst trennen und diese Workflows nicht vom Editor aus für lange Scraping-Jobs ausführen. Halte sie stattdessen mit einem Schedule Trigger aktiv und überprüfe die Ausführungshistorie, nachdem sie abgeschlossen sind. Wenn der Browser die Verbindung trennt, die Ausführung aber fortgesetzt wird, ist es meist ein UI-/Session-Problem.
Bei den HTTP Request-Teilen würde ich Batching/Pagination und kleinere Chunks hinzufügen, statt zu viele Daten in einer einzigen Anfrage abzurufen. n8n’s Dokumentation erwähnt die Verwendung von Batching, um die Anfragegröße zu reduzieren und Pausen zwischen Aufrufen einzufügen. Speichere auch den Fortschritt zwischen den Schritten, damit ein fehlgeschlagener Durchlauf fortgesetzt werden kann, statt von vorne zu beginnen.
Wenn Ausführungen wirklich mit Speicher-/Unterbruchfehlern stoppen, würde ich die Ausführungs-ID, den Zeitstempel, den Workflow-Namen und den fehlgeschlagenen Node erfassen und dann vergleichen, ob es immer bei der gleichen HTTP-Antwortgröße oder dem gleichen Endpoint passiert.
Willkommen in der Community @Raul_Martin_Acebes! Das Setup, das du beschrieben hast, ist durchdacht und du hast bereits gute Arbeit geleistet, um das Problem zu isolieren.
Aufbauend auf dem, was @tamy.santos gesagt hat, möchte ich noch ein paar weitere Dinge hinzufügen, die spezifisch für n8n Cloud Scraping-Workflows relevant sind:
1. n8n Cloud hat Execution-Timeout-Limits
Im Starter-Plan werden Workflows nach 1 Stunde unterbrochen. Wenn deine Scraping-Workflows mehrere Endpunkte in Schleifen abfragen, können sie stillschweigend dieses Limit erreichen und stoppen. Der Browser zeigt “offline” an, was oft nur bedeutet, dass die WebSocket-Sitzung unterbrochen wird, aber der eigentliche Grund ist das Execution-Timeout. Überprüfe dein Execution-Verlauf unter Settings > Executions, um zu sehen, ob sie “Error” mit einer Timeout-Meldung anzeigen.
2. Füge einen Wait-Node zwischen HTTP Request-Aufrufen ein
Für Scraping-Workflows füge einen Wait-Node (auf 1-2 Sekunden eingestellt) zwischen Batches von HTTP-Aufrufen ein. Dies verhindert Speicherspitzen und reduziert die Wahrscheinlichkeit, dass eine einzelne große Anfrage den Executor stört:
Loop > HTTP Request > Wait (1s) > nächste Iteration
3. Nutze die “Continue on fail”-Option bei HTTP Request-Nodes
Mit “Continue on fail” aktiviert + “Always Output Data” angekreuzt wird die gesamte Execution nicht unterbrochen, wenn eine Anfrage fehlschlägt. Du kannst fehlgeschlagene Items danach filtern.
4. Teile große Scraping-Jobs in kleinere zeitgesteuerte Ausführungen auf
Statt dass ein Workflow 1000 Items scr aped, teile sie in Batches von 100-200 pro Ausführung mit einem Schedule Trigger alle 15 Minuten auf. Das ist auf Cloud viel stabiler.
Kannst du grob angeben, wie viele HTTP-Requests in einem einzelnen Workflow-Durchlauf vorhanden sind und welchen Plan du nutzt? Das hilft mir, das einzugrenzen.
Vielen Dank für die Vorschläge.
Ich habe Batching mit Loop Over Items + Wait Nodes implementiert und die Workflows sind jetzt deutlich stabiler. Seit ich das gemacht habe, werden sie nicht mehr automatisch unpubliziert und die meisten Ausführungen werden korrekt abgeschlossen, selbst wenn einige Items fehlschlagen.
Jedoch sehe ich immer noch gelegentlich ein anderes Problem, das scheinbar nichts mit dem Workflow-Speicher/der Last zu tun hat:
-
Der Editor zeigt plötzlich “Offline” an, obwohl ich keinen Workflow ausführe.
-
Ich bekomme manchmal zufällige 502-Fehler wie:
-
“Error fetching workflows”
-
“Problem loading execution”
-
-
In dieser Zeit verliere ich vorübergehend den Zugriff auf die Workflow-Liste/UI
-
Dies kann auch passieren, wenn überhaupt kein Workflow läuft
Es wirkt daher eher wie ein Cloud-/UI-/Session-/Backend-Stabilitätsproblem als dass die Workflows den Speicher erschöpfen.
Kennst du die Ursache dafür? Ich erlebe das tagsüber häufig und habe eine gute Internetverbindung.
@Raul_Martin_Acebes
Es scheint eher ein vorübergehender Fehler zwischen Browser, Frontend, Backend von n8n und Proxy/Cloud zu sein, oder eine Instabilität der Cloud-Umgebung selbst. Ich würde versuchen, die genaue Uhrzeit des Problems zu erfassen, Fehler aus der Browser-Konsole/dem Netzwerk zu überprüfen und zu validieren, ob dies auch in einem anderen Browser oder in einem anonymen Fenster auftritt. Falls weiterhin Fehler auftreten, würde ich diese Informationen an den Support senden, da sie die Backend-/Proxy-Logs überprüfen können, die mit den 502-Fehlern auf ihrer Seite zusammenhängen.
Wie kontaktiere ich den Support? Ich habe versucht, den Fehler zu beheben, aber es ist mir nicht gelungen.
Hier passieren zwei separate Dinge, und es lohnt sich, sie zu trennen, weil eines davon wahrscheinlich gar kein echtes Problem ist.
Das Banner „Offline