Hinweis: n8ns „Weiter bei Fehler“ schluckt Knotenfehler – dein Ausführungsprotokoll lügt dich an

Fragen
1

Etwas, das ich in n8n-Workflows in der Produktionsumgebung ständig sehe und das viele vor Probleme stellt.

Wenn du bei einem Knoten die Option „Weiter bei Fehler“ (Continue On Fail) aktivierst, markiert n8n die Ausführung als erfolgreich, selbst wenn dieser Knoten mit einem 500er, einem 401er oder einer leeren Antwort fehlschlägt. Der Fehler wird als Fehlerausgangsdaten an nachgelagerte Knoten weitergegeben, der Workflow läuft weiter und der Ausführungsstatus auf oberster Ebene wird als grün angezeigt.

Das bedeutet: Dein HubSpot-Knoten ist fehlgeschlagen, deine CRM-Zeile wurde nie erstellt, dein Kunde hat die E-Mail nie erhalten — und der Ausführungsprotokoll von n8n zeigt Erfolg an.

Drei Bereiche, in denen dies echte Probleme verursacht:

  1. HTTP-Anfrage-Knoten mit „Weiter bei Fehler“ — ein 500er von einer API sieht in der Ausführungsansicht identisch aus wie ein 200er

  2. Code-Knoten, die Fehler auslösen — stillschweigend an nachgelagerte Knoten weitergegeben

  3. Beliebige Knoten in einem mehrstufigen Flow, bei denen du „es einfach weiterlaufen lassen willst“

Die Lösung besteht darin, nach jedem kritischen Knoten, der „Weiter bei Fehler“ verwendet, einen expliziten IF-Knoten hinzuzufügen — prüfe das Vorhandensein von $json.error in der Ausgabe und leite ihn an einen Alarmzweig weiter.

Hat jemand anderes dies in der Produktionsumgebung erlebt? Ich bin gespannt, wie man damit in größeren Workflows umgeht.

3

Gute Ergänzungen. Die inkonsistente Fehlerstruktur bringt die Leute ständig durcheinander. Es ist richtig, sowohl $json.error.message als auch $json.error als einfachen String in derselben IF-Abfrage zu behandeln.

Der Fall mit null Elementen ist in mancher Hinsicht noch tückischer als CoF. Keine Fehlerstruktur, der Flow stoppt einfach, alles Upstream zeigt grün. Ich füge explizite Elementanzahlprüfungen an Knoten ein, wo eine leere Ausgabe ein echter Fehler ist, nicht nur ein stiller Randfall.

Bezüglich Setup: Ein zentraler Error Trigger für offensichtliche Fehler, aber das lässt die CoF- und Null-Elemente-Fälle ungedeckt. Ich baue etwas Spezielles für das „grün-aber-defekt“-Muster. An welcher Stelle erleben die Leute am häufigsten, dass Null-Elemente in der Produktion Probleme bereiten?

4

Das habe ich exakt in der Produktion mit kundenorientierten Report-Workflows erlebt. Das Inline-IF-nach-CoF-Pattern funktioniert, hat aber eine strukturelle Schwachstelle: Jede Prüfung lebt innerhalb des Workflows, den sie prüft. Wenn der Flow früh stoppt (dein Zero-Items-Fall) oder jemand einen Node bearbeitet und den Check-Branch löscht, stirbt die Validierung mit ihm — und alles Upstream zeigt weiterhin Grün.

Was sich bewährt hat: Inline-Checks zum Routing behalten, aber Health-Validierung AUSSERHALB des Workflows verschieben. Jeder Production Workflow schreibt als letzten Schritt eine Zeile Run-Metadaten (Status, Item-Counts, Timestamp) in ein Log-Sheet; ein separater geplanter Watcher liest das Log und alertet bei fehlenden Runs, Error-Zeilen oder Zero-Count-Outputs. Der Watcher überlebt alles, was innerhalb der Workflows passiert, die er überwacht — einschließlich, dass sie gar nicht laufen, was kein Inline-Check je erwischen kann.

Mich würde interessieren, in welchem Umfang das für Leute anfängt wehzutun — wie viele Production Workflows laufen bei dir, wenn du deine CoF-Discipline aufgebaut hast?

5

@dima_automation Bei null Elementen, die in der Produktion verarbeitet werden – das häufigste Problem, das ich sehe, ist Google Sheets „Get Rows

6

Beide sind Schulbuchbeispiele, besonders „Sheets Get Rows