Fehlerbehandlung, Resilienz und Debugging

Fehlerbehandlung, Resilienz und Debugging

0:00 Wenn ein Workflow rot wird, ist das unangenehm — aber es ist ein guter Tag. Denn dann wissen Sie, dass etwas nicht stimmt. Der gefährliche Fall ist der andere: Der Lauf bleibt grün, das Häkchen steht, und trotzdem ist der Vorgang halb erledigt oder gar nicht. Genau dieser Fall ist das Thema dieses Moduls. Wir sehen uns an, wie n8n mit Fehlern umgeht, welche Einstellungen es dafür gibt und warum die bequemste davon zugleich die gefährlichste ist.

0:26 Und wir üben, einen Produktionsfehler so nachzustellen, dass man ihn auf Knopfdruck wiederholen kann.

Fehlerbehandlung, Resilienz und Debugging

0:33 Der dritte Tag dreht sich um Verlässlichkeit. Heute geht es nicht mehr darum, was ein Workflow kann, sondern darum, was er tut, wenn etwas schiefgeht — und darum, wer davon erfährt. Wir beginnen mit den Fehlerarten und den Fehlerpfaden, gehen dann zu Wiederholungen und Ausgleichsschritten über, üben Debugging anhand gespeicherter Läufe und enden bei der Frage, was eigentlich in eine Fehlermeldung gehört, damit jemand damit etwas anfangen kann.

Fehlerarten und Fehlerpfade

0:57 Fangen wir mit einer Unterscheidung an, die trivial klingt und Ihre gesamte Fehlerbehandlung strukturiert: Nicht jeder Fehler ist ein Ausfall — und nicht jeder Ausfall ist ein Fehler. Ein technischer Fehler heißt: Der Schritt konnte nicht ausgeführt werden. Die Gegenseite antwortet nicht, die Anmeldung schlägt fehl. Ein fachlicher Fehler heißt: Der Schritt lief, aber das Ergebnis darf nicht gelten. Die Anlage ist unbekannt, der Betrag unplausibel.

1:23 Der Unterschied ist nicht akademisch, er entscheidet über die Reaktion. Beim technischen Fehler lohnt ein zweiter Versuch — die Leitung kann beim nächsten Mal stehen. Beim fachlichen Fehler ändern auch hundert Versuche die Daten nicht. Wer beides gleich behandelt, wiederholt entweder sinnlos oder gibt zu früh auf. Drei Einstellungen, und die mittlere ist die gefährlichste im ganzen Werkzeug. Stop Workflow hält alles an — ehrlich und meistens richtig.

1:51 Continue geht mit den letzten gültigen Daten weiter; das klingt robust und ist in Wahrheit die Stelle, an der Fehler verschwinden. Continue using error output geht ebenfalls weiter, reicht aber die Fehlerinformation auf einem eigenen Ausgang heraus — das ist fast immer die bessere Wahl, denn Sie können damit etwas tun. Übrigens: Die Einstellung hieß früher Continue on Fail, heute heißt sie On Error. Wenn Sie ältere Anleitungen lesen, suchen Sie unter beiden Namen.

2:19 Ein Error Workflow ist ein eigener Workflow, der mit dem Error Trigger beginnt und läuft, wenn eine Ausführung scheitert. Sie hinterlegen ihn je Workflow in den Einstellungen — und Sie dürfen denselben für viele verwenden. Das ist der entscheidende Hinweis: Sie brauchen nicht zwanzig Fehler-Workflows, Sie brauchen einen guten. Denken Sie an die Zentrale eines Wachdienstes.

2:40 Nicht jedes Gebäude hat eine eigene; alle melden an dieselbe Stelle, und dort sitzt jemand, der weiß, was zu tun ist. Genau so sollten Sie das aufbauen. Vier Angaben stehen Ihnen im Fehler-Workflow zur Verfügung. Die Kennung und die Adresse der gescheiterten Ausführung — damit kommen Sie mit einem Klick zum Vorgang, und das ist im Ernstfall Gold wert.

3:01 Die Fehlermeldung und der zuletzt ausgeführte Baustein. Name und Kennung des betroffenen Workflows. Und die Angabe, ob der Lauf selbst schon eine Wiederholung war. Diese letzte ist unscheinbar und sehr nützlich: Sie unterscheidet den einmaligen Aussetzer von dem Fall, in dem schon mehrfach erfolglos versucht wurde — und das sind zwei verschiedene Dringlichkeiten.

3:21 Der erste Punkt ist der wichtigste dieses Moduls: Continue wird gesetzt, damit der Lauf durchgeht — und damit verschwindet der Fehler. Das ist keine Fehlerbehandlung, das ist Fehlerverdeckung. Der zweite ist eine hübsche Falle: Always Output Data auf einem If-Baustein kann eine Endlosschleife erzeugen; die Dokumentation warnt ausdrücklich davor.

3:41 Der dritte kostet Sie die Nachverfolgung: Kennung und Adresse fehlen, weil die Ausführung gar nicht gespeichert wurde. Und der vierte überrascht: Scheitert schon der Trigger, bekommt der Fehler-Workflow ganz andere Daten — mit weniger Informationen zur Ausführung.

Wiederholen, abbrechen, ausgleichen

3:56 Jetzt zur Frage, was nach einem Fehler geschehen soll. Wiederholen ist die naheliegende Antwort — aber sie hilft nur, wenn der Schritt überhaupt wiederholbar ist. Und das ist er erstaunlich oft nicht. Fünf Schritte, und die Reihenfolge ist eine Entscheidungskette. Entscheiden Sie zuerst, ob der Schritt gefahrlos wiederholt werden kann — dafür ist die Tabelle aus Modul fünf da, die Spalte mit der Wiederholbarkeit.

4:21 Wenn ja: Retry On Fail mit wachsendem Abstand statt sofortigem Neuversuch. Wenn nein: Beschreiben Sie den Ausgleichsschritt oder verschieben Sie die Wirkung ans Ende. Setzen Sie eine Grenze — nach wie vielen Versuchen ist Schluss? Und legen Sie fest, wohin der endgültig gescheiterte Vorgang wandert. Ohne diesen fünften Schritt sammeln sich gescheiterte Vorgänge an einer Stelle, die niemand kennt.

4:44 Vier Fälle, in denen der zweite Versuch das Problem vergrößert. Ein POST erzeugt beim zweiten Versuch einen zweiten Vorgang — die Wiederholbarkeits-Spalte, in ihrer teuersten Auslegung. Die Gegenseite ist überlastet, und jeder Neuversuch verschärft die Lage; das ist der Grund, warum man den Abstand vergrößert statt verkürzt.

5:03 Der Fehler ist fachlich, und hundert Versuche ändern die Daten nicht. Und der vierte ist ein Zeitproblem: Der Timeout des Aufrufers läuft ab, während n8n noch wiederholt — der Aufrufer hat dann längst abgebrochen und schickt vielleicht gleich noch einmal. Eine Dead-Letter-Ablage nimmt Vorgänge auf, die endgültig gescheitert sind.

5:23 Sie hält den Vorgang samt Fehlerursache fest, damit er später geprüft und gezielt erneut angestoßen werden kann. Der Name kommt aus der Post: der tote Brief, der weder zugestellt noch zurückgeschickt werden kann — und der eben nicht im Papierkorb landet, sondern in einem Fach, das jemand durchsieht. Genau diese Haltung brauchen Sie. Ein Vorgang, der endgültig gescheitert ist, ist kein Müll. Er ist ein Kundenanliegen, das noch offen ist.

5:49 Der erste Punkt ist eine Selbstschädigung mit Anlauf: Wiederholt wird sofort und dreimal, was die Ratenbegrenzung erst auslöst. Der zweite ist der teuerste: Die Wiederholung umfasst auch Schritte, die schon gewirkt haben — dann entstehen Doppelbuchungen. Deshalb gehört die Wiederholung auf den Schritt, nicht auf den ganzen Vorgang.

6:08 Der dritte ist eine halbe Lösung: Gescheiterte Vorgänge werden gemeldet, aber nirgends festgehalten — die Mail ist gelesen und weg. Und der vierte kostet Zeit: Der Wiederanlauf beginnt von vorn, obwohl Teilschritte bereits erledigt sind.

Debugging und reproduzierbare Fehlerfälle

6:22 Kommen wir zum Handwerk der Fehlersuche. Und da hat n8n etwas zu bieten, das man in anderen Umgebungen schmerzlich vermisst: Der Lauf von gestern ist die beste Testumgebung, die Sie haben können. Vier Mittel, die aufeinander aufbauen. Gespeicherte Ausführungsdaten zeigen Ihnen Ein- und Ausgabe jedes Bausteins — Sie sehen also nicht nur, dass es krachte, sondern womit.

6:45 Die Daten einer früheren Ausführung lassen sich in den Editor laden; damit arbeiten Sie an echten Daten, ohne sie noch einmal anzufordern. Angeheftete Daten machen den Fall dann beliebig oft wiederholbar — das ist die Technik aus Modul zwei, hier in ihrem wichtigsten Einsatz. Und der letzte Satz ist die Messlatte: Erst wenn der Fehler auf Knopfdruck auftritt, ist er verstanden. Vorher haben Sie eine Vermutung.

7:10 Fünf Schritte, die Sie sich als Ablauf merken sollten. Öffnen Sie die gescheiterte Ausführung in den Executions. Sehen Sie sich den zuletzt ausgeführten Baustein und seine Eingabe an — dort steht in neun von zehn Fällen die Antwort. Laden Sie die Daten der Ausführung in den Editor. Heften Sie die Eingabe des fehlerhaften Bausteins an und wiederholen Sie den Fall, so oft Sie wollen. Und prüfen Sie die Korrektur gegen denselben angehefteten Fall.

7:36 Ein Hinweis zur Verfügbarkeit: Das Laden früherer Ausführungsdaten setzt n8n Cloud oder eine registrierte Community-Instanz voraus — noch ein Grund, sie zu registrieren. Der erste Punkt ist der ärgerlichste, weil er die ganze Fehlersuche unmöglich macht: Die Einstellung verwirft gescheiterte Ausführungen, und es gibt schlicht nichts anzusehen.

7:56 Prüfen Sie das, bevor Sie es brauchen. Der zweite ist der Klassiker: Debuggt wird gegen frische Daten, und der Fehler tritt nicht mehr auf — dann haben Sie nichts gelernt. Der dritte ist eine halbe Protokollierung: Der Fehler steht drin, aber nicht die auslösende Eingabe. Und der vierte ist eine Frage der Gründlichkeit: Nach der Korrektur wird der ursprüngliche Fall nie erneut geprüft.

Melden statt schweigen

8:18 Zum Abschluss die Frage, die über den Betrieb entscheidet: Wer erfährt eigentlich von einem Fehler, und was steht in der Meldung? Eine Meldung ohne Kontext ist ein Alarm ohne Adresse. Vier Angaben, und die erste ist die, die am häufigsten fehlt. Welcher Vorgang ist betroffen — nicht nur welcher Workflow. Der Empfänger muss wissen, ob es um die Störungsmeldung von Frau Soundso geht oder um einen nächtlichen Abgleich. Dann die Adresse der Ausführung, damit der Weg dorthin kurz ist.

8:47 Dann, und das wird fast immer vergessen: Was soll der Empfänger tun — prüfen, wiederholen, eskalieren? Eine Meldung ohne Handlungsanweisung erzeugt nur Unruhe. Und schließlich: seit wann das Problem besteht und wie oft es aufgetreten ist. Ein Einzelfall und eine Serie verlangen verschiedene Reaktionen. Vier Wege in die Stille, und Sie kennen inzwischen alle. On Error steht auf Continue, und der leere Zweig läuft weiter.

9:13 Der Code-Node fängt jede Ausnahme und gibt ein leeres Array zurück — der Stolperstein aus dem letzten Modul. Die Gegenseite antwortet mit einem Erfolgs-Statuscode und einer Fehlermeldung im Rumpf; das kommt häufiger vor, als man glaubt, und Ihr Workflow sieht nur die Zweihundert. Und viertens: Niemand prüft am Ende, ob die Zahl der Ergebnisse zur Eingabe passt. Diese vier zusammen erklären so gut wie jeden Fall von „Es lief doch durch".

9:39 Fachliche Akzeptanzkriterien beschreiben, woran sich ein gelungener Lauf erkennen lässt — nicht technisch, sondern im Sinne des Prozesses. Nicht „alle Bausteine grün", sondern „zu jeder eingegangenen Meldung existiert ein Einsatz oder eine begründete Ablehnung". Das ist ein anderer Satz, und er lässt sich prüfen. Solche Kriterien sind die Grundlage dafür, überhaupt zu bemerken, dass etwas fehlt. Ohne sie messen Sie die Technik und hoffen auf die Fachlichkeit.

10:07 Am sechsten Tag, im Abschlussprojekt, werden diese Kriterien zum Abnahmemaßstab — merken Sie sich den Begriff. Der erste Punkt ist ein Datenschutzproblem aus guter Absicht: Protokolliert werden vollständige Datensätze samt personenbezogener Inhalte. Der zweite ist der Grund, warum Alarme irgendwann ignoriert werden: Jeder Fehler geht an alle, bis niemand mehr hinsieht. Lieber wenige, gut adressierte Meldungen.

10:32 Der dritte ist die tote Adresse — die Eskalation endet bei einem Verteiler, den niemand liest. Und der vierte ist die Zusammenfassung des ganzen Moduls: Der Erfolg wird an einem grünen Lauf gemessen statt am fachlichen Ergebnis.

Übung

10:46 Jetzt bekommen Sie einen Workflow, der zu oft grün ist. Ihre Aufgabe ist es, ihn ehrlich zu machen — und dabei alles anzuwenden, was wir gerade besprochen haben. Der Kesselwerk-Workflow legt Einsätze an, auch wenn das Ersatzteilportal nicht erreichbar war — dann eben ohne Teileangabe. Technisch ist das kein Fehler: Niemand hat gesagt, dass die Teileangabe Pflicht ist. Die Läufe sehen erfolgreich aus.

11:11 Und die Folge steht im letzten Satz: Die Technikerinnen und Techniker fahren ohne das benötigte Teil zum Einsatz. Das ist die Sorte Fehler, die man nicht im Monitoring findet, sondern in der Beschwerde. Und sie ist deshalb so verbreitet, weil jeder einzelne Baustein genau das getan hat, was man ihm gesagt hat. Das Lernziel: Fehlerpfade so einrichten, dass ein unvollständiges Ergebnis nicht als Erfolg durchgeht.

11:36 Erfolgreich sind Sie, wenn ein Ausfall des Portals zu Wiederholung mit wachsendem Abstand führt, danach zu einem gemeldeten und festgehaltenen Vorgang — und nie zu einem Einsatz ohne Teileangabe. Achten Sie auf dieses Nie: Es gibt keine Variante, in der der Einsatz trotzdem entsteht. Wer früh fertig ist, ergänzt eine Ablage für endgültig gescheiterte Vorgänge samt Wiederanlauf.

11:58 Damit haben Sie die Dead-Letter-Ablage aus dem zweiten Kapitel gebaut, nicht nur besprochen. Eine Stunde, fünf Schritte. Stellen Sie zuerst den Ausfall des Portals nach — Sie brauchen den Fehlerfall, bevor Sie ihn behandeln können. Verfolgen Sie dann den Weg, den die Daten dabei nehmen; das ist der Erkenntnisschritt, überspringen Sie ihn nicht.

12:19 Setzen Sie On Error und Retry On Fail passend zum jeweiligen Schritt — passend heißt: nicht überall gleich. Legen Sie einen Error Workflow mit Kontext und Handlungsanweisung an, so wie im vierten Kapitel besprochen. Und lösen Sie den Fall erneut aus, um zu prüfen, dass kein Einsatz entsteht. Vier Fallen, und die erste ist die häufigste überhaupt: Der Fehlerzweig wird gebaut, aber nie ausgelöst und damit nie getestet.

12:44 Ein ungetesteter Fehlerpfad ist kein Fehlerpfad, sondern eine Absichtserklärung. Die zweite: Die Meldung nennt den Workflow, aber nicht den betroffenen Vorgang — der Punkt aus dem vierten Kapitel. Die dritte ist die teure: Wiederholt wird auch der Schritt, der den Einsatz bereits angelegt hat. Und die vierte ist die hinterhältigste: Der Error Workflow scheitert selbst und meldet das niemandem. Wer wacht über den Wächter?