Wenn ein Schritt schief­geht

Zwischen zwei Schritten eines Ablaufs liegt immer eine Stelle, an der der eine fertig ist und der nächste noch nicht begonnen hat. Bricht der Ablauf dort ab, liegt ein Teil der Arbeit schon vor, und der Rest fehlt. Dieses Kapitel fragt, was dann zu tun ist, und wie man einen Ablauf so baut, dass ein zweiter Lauf nichts doppelt tut und nichts verliert. Das Beispiel ist der Rechnungseingang aus Kapitel 01.

Was nach dem Abbruch wo liegt

Das erste Kapitel endete mit der Liste, in der jemand die Rechnung freigibt. Danach geht der Ablauf weiter. Er bucht die Rechnung in der Buchhaltung und legt das PDF mit der Buchungsnummer im Archiv ab.

Angenommen, die Buchung geht hinaus, kommt in der Buchhaltung an, und dann reißt die Verbindung ab, bevor die Bestätigung zurück ist. Für den Ablauf ist der Schritt gescheitert. Im Archiv fehlt das PDF, und der Ablauf weiß nicht, ob gebucht wurde. Startet ihn jemand einfach noch einmal, steht die Rechnung zweimal in den Büchern. Lässt man ihn liegen, gibt es eine Buchung ohne Beleg im Archiv. Beides fällt erst auf, wenn jemand die Konten abgleicht.

Den Kern dieses Falls beschreibt Grundkurs, Kapitel 09 in der dritten Ebene, für ein Werkzeug, das etwas ändert: Hinter einer Zeit­über­schrei­tung kann eine Buchung stehen, und wer wiederholt, ohne vorher nachzusehen, bucht zweimal. Dieses Kapitel baut die Antwort darauf aus.

Drei Antworten eines Schritts auf einen Fehler

In Agenten und Harness, Kapitel 01 steht in der dritten Ebene eine Prüffrage für die Grenze zum Agenten: Wer sucht den Ausweg, wenn ein Schritt scheitert? Steht er als Wiederholung oder Ersatzpfad im Programm, ist es ein Ablauf. Dieser Abschnitt beschreibt die Wege, die dafür im Programm stehen.

Ein Ablauf kann auf einen gescheiterten Schritt auf drei Arten reagieren: anhalten, weitermachen oder wiederholen. In n8n, dem Baukasten aus dem ersten Kapitel, stehen alle drei als Einstellungen eines Knotens (externe Seite, docs.n8n.io) zur Wahl. Anhalten heißt, der ganze Ablauf steht still. Weitermachen gibt es in zwei Fassungen. Die eine geht zum nächsten Knoten mit den letzten gültigen Daten. Die andere reicht die Angaben zum Fehler an den nächsten Knoten weiter, der darauf reagieren kann.

Für den Rechnungseingang ist die erste Fassung des Weitermachens die gefährlichste. Scheitert der Modellschritt, bekommt die Prüfung keine gelesenen Felder. Je nach Knoten reicht n8n die Eingabe des Modellschritts weiter, oder der Knoten gibt einen Eintrag aus, der nur die Fehlermeldung enthält. Beides steht so im Quelltext (externe Seite, raw.githubusercontent.com), die Doku spricht allgemein von den letzten gültigen Daten. Ob die Prüfung das bemerkt, hängt allein daran, wie streng sie gebaut ist.

Wiederholen heißt in n8n Retry On Fail. Die Doku beschreibt es als Wiederholung, bis der Knoten gelingt. Im Quelltext (externe Seite, raw.githubusercontent.com) ist die Zahl der Versuche begrenzt, in der Fassung vom 16.10.2026 auf zwei bis fünf, voreingestellt drei. Dazwischen liegt eine feste Pause von höchstens fünf Sekunden, voreingestellt eine Sekunde, und sie wird von Versuch zu Versuch nicht länger. Doku und Quelltext weichen hier voneinander ab. Für den Betrieb gilt, was im Quelltext steht.

Ein Fehler muss sich melden

Ein angehaltener Ablauf fällt zunächst niemandem auf. Damit jemand davon erfährt, kennt n8n den Fehlerablauf (externe Seite, docs.n8n.io). Das ist ein eigener Ablauf, der startet, wenn eine Ausführung scheitert, und zum Beispiel eine Mail oder eine Nachricht in einen Chat schickt. Ein Fehlerablauf kann für viele Abläufe zuständig sein.

Zwei Eigenheiten stehen in der Doku. Der Fehlerablauf springt nur an, wenn ein automatisch gestarteter Ablauf (externe Seite, docs.n8n.io) scheitert. Wer ihn im Editor von Hand ausprobiert, sieht ihn also nie arbeiten, erst beim ersten echten Fehler im Betrieb. Außerdem reagiert er auf das, was n8n als Fehler erkennt, laut Doku meist eine falsche Einstellung an einem Knoten oder zu wenig Speicher. Hält der Ablauf selbst eine Antwort für unbrauchbar, setzt man einen eigenen Knoten namens Stop And Error. Er lässt die Ausführung absichtlich scheitern und löst so den Fehlerablauf aus.

Was ein stiller Abbruch kostet, zeigt der Meldungsautomat dieser Seite. Vier Tage lang bewertete er nichts, und jeder Lauf endete ohne Fehlercode. Die Überwachung sah saubere Läufe. Seitdem meldet der Ablauf einen Abbruch selbst, einmal je neuem Grund.

Dasselbe gilt für einen Ablauf, der auf eine Freigabe wartet. Der Warteknoten von n8n legt die Ausführung dafür in der Datenbank ab und kann nach einer eingestellten Frist (externe Seite, docs.n8n.io) von selbst weiterlaufen. Was nach der Frist mit der Rechnung geschieht, muss im Ablauf stehen: eine Erinnerung, eine Vertretung, die freigibt, oder ein Fehler, der sich meldet.

Ein zweiter Lauf darf nichts doppelt tun

Die Fachsprache hat dafür ein Wort: idempotent. Ein Vorgang ist idempotent, wenn es dieselbe Wirkung hat, ihn zweimal zu verlangen oder einmal. So definiert es die HTTP-Spezifikation (externe Seite, rfc-editor.org), und sie misst an der beabsichtigten Wirkung beim Empfänger. Die Antwort darf beim zweiten Mal anders ausfallen.

Daraus leitet der Standard ab, wann ein Programm eine Anfrage von selbst wiederholen darf. Eine Anfrage mit einer Methode, die nicht als idempotent gilt, etwa eine, die etwas anlegt, soll es nur unter einer von zwei Bedingungen wiederholen. Entweder weiß es, dass gerade diese Anfrage trotzdem idempotent ist, oder es kann feststellen, dass die erste nie angekommen ist. Das sind die beiden Auswege des Rechnungseingangs. Der Ablauf sieht vor dem zweiten Versuch in der Buchhaltung nach, ob die Rechnung schon gebucht ist. Oder er schickt mit jeder Buchung einen Schlüssel mit, an dem die Buchhaltung einen zweiten Versuch erkennt und abweist.

Den Schlüssel muss man nicht erfinden. Das Umsatz­steu­er­ge­setz (externe Seite, gesetze-im-internet.de) verlangt auf einer Rechnung eine Nummer, die der Aussteller einmalig vergibt, dazu seine Steuernummer oder Umsatzsteuer-Iden­ti­fi­ka­ti­ons­nummer. Beide zusammen bezeichnen genau eine Rechnung. Zwei Ausnahmen regelt die Durch­füh­rungs­ver­ord­nung (externe Seite, gesetze-im-internet.de): Eine Rechnung bis 250 Euro und die Rechnung eines Kleinunternehmers (externe Seite, gesetze-im-internet.de) müssen keine Rechnungsnummer enthalten. Für sie bleibt die Kennung der Mail oder der Abgleich von Hand.

Eine Buchhaltung, die auf diesen Schlüssel achtet, weist dieselbe Rechnung beim zweiten Mal ab, gleich wie oft der Ablauf es versucht. Ob die eigene Buchhaltung das kann, steht in ihrer Schnitt­stel­len­doku, und das gehört zu den ersten Fragen vor dem Bau.

Was beim Modellschritt hinzukommt

Der Modellschritt bringt zwei Fehlerarten mit, die ein Schritt aus Code nicht kennt. Die erste ist ein Scheitern ohne Fehler. Lehnt ein Sicherheitsfilter des Modells eine Anfrage ab, kommt die Antwort laut Anthropic (externe Seite, platform.claude.com) als gewöhnliche Antwort mit dem Statuscode 200 zurück. Woran sie zu erkennen ist, steht in einem eigenen Feld der Antwort, dem Stoppgrund (stop_reason). Dort steht auch, wenn eine Antwort an der eingestellten Höchstzahl an Token abgeschnitten ist. Ein Ablauf, der nur auf den Statuscode achtet, reicht beides an die Prüfung weiter.

Der Hersteller empfiehlt, an diesem Feld zu entscheiden, ob man die Antwort nimmt, fortsetzt, wiederholt oder ein anderes Modell fragt.

Die zweite: Beim zweiten Mal liest der Modellschritt womöglich anders. Dieselbe Eingabe ergibt bei einem Sprachmodell nicht immer dieselbe Ausgabe, warum, erklärt Grundkurs, Kapitel 12. Wird der Modellschritt wiederholt, kann eine Ziffer der Rechnungsnummer anders herauskommen, und mit ihr der Schlüssel. Ein Schlüssel aus der Ausgabe des Modells ist deshalb so verlässlich wie die Lesung, aus der er stammt. Einen zweiten Schlüssel, der ohne Modell auskommt, beschreibt die zweite Ebene.

Was ohne Modell ginge

Fast alles in diesem Kapitel. Anhalten, weitermachen, wiederholen, melden und einen Schlüssel prüfen sind Programm. Die Regel aus der HTTP-Spezifikation gilt für jede Anfrage im Netz, mit Modell oder ohne. Der Modellschritt fügt zwei Fehlerarten hinzu, die ohne Fehlercode auskommen, und eine Lesung, die beim zweiten Mal anders ausfallen kann. Die Wege, einen Fehler zu behandeln, bleiben dieselben. Hinzu kommt eine Prüfung mehr, nämlich die des Feldes, das den Grund für das Ende der Antwort nennt.

Die erste Ebene hat den Abbruch zwischen Buchen und Ablegen beschrieben und die beiden Auswege genannt: nachsehen oder einen Schlüssel mitschicken. Diese Ebene fragt, warum der Ausgang einer Anfrage oft offen bleibt und wie viele Wiederholungen ein Ablauf verträgt. Danach geht es um die Herkunft des Schlüssels und um die Fehler, die nur der Modellschritt hat.

Der dritte Ausgang einer Anfrage

Ein Programm erwartet von einer Anfrage Erfolg oder Fehler. Es gibt einen dritten Ausgang, und der Zahlungsdienst Stripe beschreibt ihn in seiner Fehlerdoku (externe Seite, docs.stripe.com) besonders deutlich. Eine Verbindung kann abreißen, bevor die Antwort da ist. Steht die Verbindung wieder, weiß das Programm trotzdem nicht, ob die erste Anfrage gelungen ist.

Dasselbe gilt für einen Serverfehler mit Status 500. Stripe behandelt den Ausgang dann als offen: Die Anfrage kann etwas bewirkt haben, obwohl ein Fehler zurückkam. Ein neuer Versuch mit neuem Schlüssel ist erst erlaubt, wenn der erste Ausgang geklärt ist. Für den Rechnungseingang heißt das: Eine Buchung mit offenem Ausgang geht nur mit demselben Schlüssel noch einmal hinaus. Ohne Schlüssel wird sie vorher geklärt.

Der Prüflauf, der auf dieser Seite die Belege abruft, führt denselben Ausgang als eigenen Stand. Manche Antworten sagen nichts über die Adresse, etwa eine Zeit­über­schrei­tung oder eine Abweisung wegen Überlast. Scheitert ein Abruf daran, gilt die Quelle als unklar, und der Lauf schreibt nichts um. Antwortet die Adresse mit 404 oder 410, ist das ein Befund.

Damit ein offener Stand nicht für immer schweigt, gilt als Befund, was seit 14 Tagen nicht mehr erreicht wurde. Ein Modell kommt in diesem Ablauf nicht vor.

Wiederholen mit Maß

Welcher Fehler einen zweiten Versuch verdient, steht in Grundkurs, Kapitel 11, in der zweiten und dritten Ebene: eine Ratengrenze mit Wartezeit ja, eine fehlerhafte Anfrage nie. Neu ist hier die Frage, wie viele Schichten wiederholen. Ein Ablauf ruft einen Knoten, der Knoten eine Bibliothek, die Bibliothek eine Schnittstelle, und jede Schicht kann eigene Versuche machen.

Marc Brooker rechnet das in einem Aufsatz aus Amazons Builders’ Library (externe Seite, builder.aws.com) vor. Fünf Schichten übereinander, jede mit drei Versuchen, vervielfachen die Last auf die Datenbank am Ende um das 243-Fache. Ist der Grund des Fehlers eine Überlast, machen Wiederholungen die Lage schlimmer. Amazons Regel für günstige Vorgänge lautet deshalb, an genau einer Stelle zu wiederholen. Der Aufsatz beschreibt die eigene Bauweise des Herstellers.

Die HTTP-Spezifikation (externe Seite, rfc-editor.org) zieht eine verwandte Grenze in einem Satz: Eine gescheiterte automatische Wiederholung soll ein Programm nicht noch einmal automatisch wiederholen.

Am eigenen Ablauf wird daraus eine Rechnung mit Annahmen. Anthropics offizielle Bibliothek wiederholt laut Fehlerdoku (externe Seite, platform.claude.com) in der Voreinstellung zweimal, macht also drei Versuche. Ein Knoten mit Retry On Fail macht in der Voreinstellung ebenfalls drei. Ruft ein solcher Knoten diese Bibliothek mit ihren Voreinstellungen, werden aus einem gescheiterten Modellschritt bis zu neun Aufrufe. Wer den Knoten wiederholen lässt, sieht deshalb zuerst nach, ob die Bibliothek darunter schon selbst wiederholt.

Der Schlüssel kommt aus dem Vorgang

Gegen eine doppelte Buchung hilft ein Schlüssel, der bei jedem Versuch derselbe ist. Die Kennung einer Ausführung taugt dafür nicht.

Wiederholt man in n8n eine gescheiterte Ausführung, entsteht eine neue mit eigener Kennung. Die gescheiterte steht in einem eigenen Feld, das der Fehlerablauf (externe Seite, docs.n8n.io) nur bei einer Wiederholung bekommt. Im Beispiel der Doku hat die Wiederholung die Kennung 231 und verweist auf die Ausführung 34.

Das Ablaufwerkzeug Temporal schlägt einen Schlüssel aus zwei Kennungen vor, der Ausführung und der Aktivität. Laut Doku (externe Seite, docs.temporal.io) bleibt er über Wiederholungen gleich und ist zwischen zwei Ausführungen verschieden. Prüfen muss ihn der Dienst, den die Aktivität aufruft. Genau darin liegt die Grenze für den Rechnungseingang: Startet dieselbe Mail aus irgendeinem Grund einen zweiten Ablauf, ist das eine neue Ausführung mit neuem Schlüssel.

Stripe empfiehlt in der Fehlerdoku (externe Seite, docs.stripe.com) zwei Wege. Der Schlüssel ist entweder zufällig, oder er stammt aus dem Gegenstand selbst, etwa der Kennung eines Warenkorbs. Wer über Neustarts hinweg wiederholt, speichert ihn und schickt ihn bei jedem Versuch mit. Ein Schlüssel, der bei jedem Versuch neu entsteht, schützt vor nichts. Die Schnitt­stel­len­doku (externe Seite, docs.stripe.com) ergänzt eine zweite Sicherung: Kommt derselbe Schlüssel mit anderen Angaben, gibt der Server einen Fehler zurück.

Am Rechnungseingang gibt es zwei solche Schlüssel aus dem Vorgang, und sie schützen gegen verschiedene Fälle.

• Die Kennung der Mail. Jede Mail soll laut Mailformat (externe Seite, rfc-editor.org) eine Message-ID haben, die der absendende Rechner einmalig vergibt. Sie steht im Kopf der Mail und kommt ohne Modell aus. Sie schützt gegen einen zweiten Lauf über dieselbe Mail. Eine zweite Mail mit derselben Rechnung, etwa eine Mahnung, hat eine neue Kennung. Und weil die Norm das Feld nur empfiehlt, kann es fehlen.
• Aussteller und Rechnungsnummer. Nach dem Umsatz­steu­er­ge­setz (externe Seite, gesetze-im-internet.de) bezeichnen beide zusammen genau eine Rechnung, ohne Frist. Eine Rechnung bis 250 Euro braucht allerdings keine Nummer, die erste Ebene nennt die Ausnahme. Sie schützen auch gegen die Mahnung. Beide Werte liest aber der Modellschritt aus dem PDF, und eine andere Lesung ergibt einen anderen Schlüssel.

Daraus folgt, als eigene Folgerung aus beiden Quellen, eine Arbeitsteilung. Die Kennung der Mail sperrt den zweiten Lauf, bevor der Modellschritt überhaupt liest. Aussteller und Rechnungsnummer sperren in der Buchhaltung, und eine Abweisung dort geht an einen Menschen, der nachsieht.

Fehler, die nur ein Modellschritt hat

Die Fehlerliste der Schnittstelle steht in Grundkurs, Kapitel 11. Für einen Ablauf zählt eine andere Einteilung, nämlich woran er einen Fehler erkennt. Ein Teil der Fehler eines Modellschritts kommt mit Fehlercode, ein Teil als gewöhnliche Antwort, und ein Teil ganz ohne Signal.

Die ersten beiden Zeilen stammen von Anthropics Seite zu Stoppgründen (externe Seite, platform.claude.com). Sie trennt Stoppgründe, die in jeder erfolgreichen Antwort stehen, von Fehlern mit Status 4xx oder 5xx. Eine Ablehnung gehört zur ersten Gruppe. Für eine abgeschnittene Antwort nennt die Seite zwei Wege, die Grenze anzuheben oder die Antwort fortzusetzen.

Zur Ablehnung ergänzt die Seite über Ablehnungen und Ersatzmodelle (externe Seite, platform.claude.com) zwei Dinge. Eine Ablehnung kann auch mitten im Strom kommen, nach einem Teil der Ausgabe. Dieser Teil gilt als unvollständig und wird verworfen. Wie der Ausweg über ein anderes Modell aussieht, beschreibt Conversational AI, Kapitel 07 in der zweiten Ebene. Eine Kategorie hat allerdings kein empfohlenes Ersatzmodell: reasoning_extraction. Sie entsteht meist, wenn der Prompt das Modell auffordert, sein Denken in die Ausgabe zu schreiben, etwa in ein Feld reasoning für den Denkweg. Eine kurze Erklärung des Ergebnisses ist laut Seite weiter möglich.

Eine solche Ablehnung wird laut Seite, Stand September 2026, abgerechnet wie jede andere Anfrage, auch wenn sie vor jeder Ausgabe kommt. Die Seite rät in diesem Fall, den Prompt zu ändern. Ein Feld für den Denkweg im Schema des Rechnungseingangs ist also eine Fehlerquelle mit Kosten, und eine Wiederholung hilft dort wenig.

Die dritte Zeile ist der leiseste Fall. Die strukturierte Ausgabe (externe Seite, platform.claude.com) sichert die Form einer Antwort. Für die Schreibweise fester Werte nennt die Doku eine Lücke. Das Modell kann einen Wert liefern, der sich vom Schema nur in Groß- und Kleinschreibung unterscheidet, meist im ersten Buchstaben nach einem Leerzeichen. Die Antwort endet dabei normal, ohne Fehler und ohne eigenen Stoppgrund.

Eine Weiche, die eine Kategorie wie „Rechnung Inland“ Zeichen für Zeichen vergleicht, schickt die Rechnung dann in keinen ihrer Zweige. Die Doku rät, solche Werte ohne Rücksicht auf die Schreibweise zu vergleichen.

Die vierte Zeile ist die Regel aus Grundkurs, Kapitel 15: Aus einem gültigen Schema folgt keine richtige Angabe. Die letzte stammt aus der Fehlerdoku (externe Seite, platform.claude.com). Wer die Antwort als Strom empfängt, kann einen Fehler bekommen, nachdem die Schnittstelle schon Status 200 gemeldet hat.

Das Ergebnis des Modellschritts wird festgehalten

Im Rechnungseingang liest der Modellschritt ein PDF und gibt Felder zurück. Was nach außen wirkt, geschieht erst in der Buchung. Eine Wiederholung des Modellschritts legt also nichts doppelt an. Sie kostet aber einen weiteren Aufruf und kann andere Felder liefern. Deshalb lohnt es sich, das erste gültige Ergebnis festzuhalten und bei einem zweiten Versuch des Ablaufs wiederzuverwenden.

In n8n geschieht das bei einer Wiederholung über die Liste der Ausführungen (externe Seite, docs.n8n.io) von selbst. Die Doku sagt nur, dass die Wiederholung mit den Daten der gescheiterten Ausführung läuft. Ab welchem Knoten, steht im Quelltext (externe Seite, raw.githubusercontent.com). Verworfen wird nur das Ergebnis des zuletzt gelaufenen Knotens, und nur dann, wenn es ein Fehler war. Was davor gelang, auch der Modellschritt, läuft nicht noch einmal. Eine gelungene Ausführung lässt sich gar nicht wiederholen.

Für den Rechnungseingang heißt das: Scheitert die Ablage nach einer gelungenen Buchung, bucht die Wiederholung nicht doppelt. Gefährlich bleibt der Fall vom Anfang. Kommt die Buchung an und die Antwort nicht, gilt der Buchungsknoten als gescheitert und läuft bei der Wiederholung noch einmal. Dagegen hilft nur der Schlüssel aus dem Vorgang.

Bei der Sta­pel­ver­ar­bei­tung von Anthropic hat jede Anfrage ihr eigenes Ergebnis. Ein Stapel mit den Rechnungen eines Tages liefert laut Doku (externe Seite, platform.claude.com) je Anfrage ein eigenes Ergebnis: gelungen, mit Fehler, abgebrochen oder abgelaufen. Für die drei gescheiterten Ausgänge fallen keine Kosten an. Die Ergebnisse kommen in beliebiger Reihenfolge zurück, zugeordnet werden sie über eine Kennung, die man jeder Anfrage selbst mitgibt. Ein Stapel ist damit ein Teilerfolg mit Ansage. Nachgeholt werden die Rechnungen ohne gelungenes Ergebnis, dazu die gelungenen mit dem Stoppgrund refusal oder max_tokens. Eine Ablehnung kommt im Stapel laut Ablehnungsseite (externe Seite, platform.claude.com) als gelungenes Ergebnis zurück.

Die beiden Ebenen davor haben gefragt, wie ein Ablauf auf einen Fehler reagiert und wie ein zweiter Lauf nichts doppelt bucht. Hier geht es um den Zustand dazwischen. Was hält ein halb gelaufener Ablauf fest, und wo muss die Sperre gegen doppelte Buchungen sitzen? Und was ist zu tun, wenn sich etwas nicht zurücknehmen lässt?

Wo ein halb gelaufener Ablauf seinen Stand hat

Ein Ablauf kann nur dort weitermachen, wo er stand, wenn dieser Stand irgendwo gespeichert ist. In n8n ist das eine Einstellung des Ablaufs (externe Seite, docs.n8n.io). Sie legt fest, ob die Daten jedes einzelnen Knotens gespeichert werden. Ist sie an, setzt der Ablauf nach einem Fehler dort wieder auf, wo er stehen blieb, und die Doku nennt die Kosten gleich dazu: Der Ablauf kann langsamer werden.

Make, ein weiterer Baukasten für Abläufe, bewahrt einen gescheiterten Lauf auf Wunsch als unvollständige Ausführung (externe Seite, help.make.com) auf. Make kann ihn später bei bestimmten Fehlerarten automatisch wiederholen, oder jemand bearbeitet ihn von Hand. Make beschreibt das als Schutz gegen Datenverlust. In der Voreinstellung ist es ausgeschaltet. Bei beiden Werkzeugen ist das Wiederaufsetzen also eine Entscheidung beim Bau.

Einen halb gelaufenen Ablauf kann die Software auch selbst erzeugen. Für eine selbst betriebene n8n-Instanz lässt sich ein Zeitlimit (externe Seite, docs.n8n.io) je Ausführung setzen. Läuft der Ablauf im Hauptprozess, wirkt es erst, wenn der laufende Knoten fertig ist. Läuft er in einem eigenen Prozess, versucht n8n zuerst den sanften Abbruch. Greift er nicht, wartet n8n noch ein Fünftel der eingestellten Zeit und beendet dann den Prozess. Ein beendeter Prozess kann einen Knoten mitten in seiner Arbeit treffen, etwa nachdem die Buchung abgeschickt und bevor ihre Antwort gelesen ist.

Was danach gespeichert ist, hängt am Zeitpunkt. Der Quelltext (externe Seite, raw.githubusercontent.com) von n8n kommentiert die Wiederholung nach einem Absturz knapp: Dann liege vom zuletzt gelaufenen Knoten nur eine Erfolgsmeldung vor. Für einen Knoten, der gerade lief, ist damit keine Aussage getroffen.

Das Ablaufwerkzeug Temporal beschreibt denselben Moment von der anderen Seite. Eine Aktivität, bei Temporal ein einzelner Arbeitsschritt, läuft erfolgreich durch, und der ausführende Prozess stürzt ab, kurz bevor er das meldet. Laut Doku (externe Seite, docs.temporal.io) gilt der Schritt dann als nicht erledigt und wird wiederholt. Ist der Schritt nicht idempotent, heißt das bei einer Zahlung: doppelte Abbuchung.

Temporal rät außerdem zu kleineren Schritten, einem je Teilaufgabe. Bei einem Fehler läuft dann nur der gescheiterte Schritt noch einmal. Den Aufwand nennt die Doku daneben, eine längere Ereig­nis­ge­schichte mit mehr Einträgen. Für den Rechnungseingang heißt das: Buchen und Ablegen sind zwei Knoten. Steckten sie in einem, liefe bei einem Fehler in der Ablage auch die Buchung noch einmal.

Buchung und Vermerk gehören in einen Vorgang

Ein Ablauf, der vor dem Buchen in der Buchhaltung nachsieht, lässt ein Zeitfenster offen. Laufen zwei Ausführungen derselben Rechnung gleichzeitig, sehen beide nach, finden nichts und buchen beide. Sicher wird die Sperre erst beim Empfänger, wenn er Schlüssel und Buchung in einem einzigen Vorgang schreibt.

Malcolm Featonby beschreibt diese Regel in einem Aufsatz aus Amazons Builders’ Library (externe Seite, aws.amazon.com), als Selbstauskunft über die eigenen Schnittstellen. Das Ziel ist, dass ein Aufruf nur einmal wirkt, auch wenn er mehrmals geschickt wird. Dafür muss der Dienst den Schlüssel und alle Änderungen so schreiben, dass entweder alles gelingt oder nichts. Sonst entstehen zwei Zustände, die keiner haben will: Der Schlüssel steht da und die Änderung fehlt, oder die Änderung steht da und der Schlüssel fehlt.

Kommt derselbe Schlüssel mit anderen Angaben, weisen Amazons Schnittstellen die Anfrage als Fehler ab. Dafür speichern sie die Angaben der ersten Anfrage mit. Am Rechnungseingang deckt diese zweite Sicherung einen Fall auf, den die erste übersieht: Der Modellschritt hat beim zweiten Mal einen anderen Betrag gelesen, die Nummer aber gleich.

In der Doku von Temporal steht dieselbe Regel: Den Schlüssel prüft der Dienst, den der Schritt aufruft. Für den Rechnungseingang ist das die Buchhaltung. Der Ablauf kann bei ihr nachfragen, die Sperre setzt sie selbst.

Wo ein Duplikatfilter zu früh vermerkt

n8n hat einen eigenen Knoten, der doppelte Elemente aussortiert (externe Seite, docs.n8n.io), auch gegen frühere Ausführungen. Die Doku nennt als Anlass einen Kunden, der dieselbe Bestellung mehrfach abschickt. Für den Abgleich über Ausführungen hinweg merkt sich der Knoten in der Voreinstellung 10.000 Einträge.

Wann der Knoten ein Element als gesehen vermerkt, sagt die Doku nicht. Im Quelltext (externe Seite, raw.githubusercontent.com) sind Prüfen und Vermerken ein einziger Aufruf. Ein Element gilt also als verarbeitet, sobald der Knoten es durchgelassen hat. Was danach scheitert, ändert daran nichts.

Daraus folgt für den Rechnungseingang, als Lesung des Quelltexts:

• Steht der Filter vor der Buchung und scheitert die Buchung, verwirft ein neuer Lauf über dieselbe Mail die Rechnung als Doppel. Sie wird nie gebucht. Eine Wiederholung derselben Ausführung ist davon ausgenommen, denn sie setzt hinter dem Filter an, wie die zweite Ebene beschreibt.
• Steht er hinter der Buchung, vermerkt er erst nach dem Buchen. Gegen eine zweite Buchung im nächsten Lauf hilft er dann nicht mehr.

An der Stelle des Filters hängt also, ob ein Fehler doppelt bucht oder gar nicht. Der Filter spart doppelte Arbeit, etwa einen zweiten Modellaufruf. Die Sperre gegen eine doppelte Buchung gehört in die Buchhaltung, an den Schlüssel aus der zweiten Ebene.

Zurückrollen nur mit Transaktion, sonst ausgleichen

Make bietet einen Fehlerbehandler, der einen Lauf zurückrollt (externe Seite, help.make.com). Er hält das Szenario an und nimmt die Änderungen der Module zurück, die Transaktionen kennen, etwa einer Datenbank. Was ein Modul ohne Transaktion getan hat, kann Make laut Doku nicht rückgängig machen; als Beispiel nennt sie eine verschickte Mail. Und ist in den Einstellungen das sofortige Festschreiben an, gelten die Änderungen der früheren Module schon als festgeschrieben und lassen sich nicht mehr zurückrollen.

Für alles andere gibt es das Ausgleichen. Hector Garcia-Molina und Kenneth Salem haben dafür 1987 den Begriff Saga (externe Seite, cs.cornell.edu) eingeführt. Eine lange Transaktion gilt nach ihrer Arbeit als Saga, wenn sie sich als Folge kleinerer Transaktionen schreiben lässt. Das System sorgt dann dafür, dass entweder alle gelingen oder ausgleichende Transaktionen den gelaufenen Teil berichtigen. Am Rechnungseingang wäre die ausgleichende Transaktion eine Gegenbuchung, die eine falsche Buchung aufhebt.

Wo sich etwas weder zurückrollen noch ausgleichen lässt, gehört eine Freigabe davor. Wo sie im Ablauf sitzt, beschreibt Kapitel 01 in der dritten Ebene.

Abgleich als letzter Weg

Manchmal klärt sich der Ausgang einer Anfrage nicht. Stripe bewahrt Schlüssel laut Fehlerdoku (externe Seite, docs.stripe.com) mindestens 24 Stunden auf. Danach kann derselbe Schlüssel eine neue Anfrage auslösen. Ist der Ausgang nach dieser Frist noch offen, rät Stripe von jedem weiteren Versuch ab, mit altem wie mit neuem Schlüssel. Stattdessen wird abgeglichen: Man sieht den Gegenstand beim Dienst nach und stellt fest, was geschehen ist.

Amazon beschreibt denselben Schritt für einen Fall ohne Antwort. Eine einfache Wiederholung könnte doppelt anlegen, also muss der Ablauf erst feststellen (externe Seite, aws.amazon.com), ob die Sache schon läuft.

Die Frist von 24 Stunden zeigt den Unterschied zwischen einem technischen und einem fachlichen Schlüssel. Kommt dieselbe Rechnung drei Wochen später als Mahnung, kann ein technischer Schlüssel bei Stripe längst gelöscht sein. Aussteller und Rechnungsnummer gelten ohne Frist, sofern die Rechnung eine Nummer enthält.

Abgleichen ist Arbeit für einen Menschen, und sie gelingt nur, wenn er findet, was er braucht. Dazu gehören die Liste der Ausführungen mit dem zuletzt gelaufenen Knoten, die Fehlermeldung und bei einem Modellschritt die Kennung, die jede Antwort der Schnittstelle mitbringt. Wie man diese Kennung protokolliert, steht in Grundkurs, Kapitel 11, dritte Ebene.

Drei Bauformen aus den Automaten dieser Seite

Die Automaten, die diese Seite betreiben, haben dieselben Fragen beantworten müssen. Drei Bauformen haben sich gehalten. Alle drei kommen ohne Modell aus.

Den Zustand am Ende schreiben und erst dann vorrücken. Der Meldungsautomat merkt sich, welche Funde entschieden sind, und schlägt sie nicht noch einmal vor. Den Zeitpunkt, bis zu dem er gelesen hat, setzt er erst am Ende vor, und nur, wenn nichts liegen blieb. Sonst fielen die Reste beim nächsten Lauf aus dem Zeitfenster und wären verloren, ohne dass jemand sie angesehen hat. Seit dem 27.09.2026 hält eine unlesbare Zustandsdatei den Lauf an. Vorher begann der Lauf dann von vorn und schlug jeden schon entschiedenen Fund erneut vor, jeden mit einem bezahlten Modellaufruf.

Über eine Zwischendatei schreiben. Derselbe Automat schreibt seine Zustandsdateien zuerst in eine Zwischendatei und benennt sie dann um. Ein abgebrochener Lauf hinterlässt so entweder die alte Datei oder die neue, jeweils vollständig.

Halb Fertiges auf einem eigenen Zweig ablegen. Ein Nachtlauf bearbeitet offene Aufgaben am Code dieser Seite. Er arbeitet in einer eigenen Kopie des Projekts auf einem eigenen Zweig, fasst die Hauptlinie nicht an und veröffentlicht nichts. Was nachts entsteht, sieht morgens ein Mensch an, bevor es übernommen wird. Das ist die Idee der Zwischendatei eine Ebene höher: Die Übernahme ist ein einzelner Schritt am Ende.

Fehlt dem Nachtlauf eine Vorbedingung, etwa der Zugang, endet er mit einem eigenen Rückgabewert für „bewusst nichts getan“. Er meldet das einmal, weil es in der nächsten Runde nicht von selbst heilt.

Dieselbe Frage stellt sich an einer Protokollgrenze. Im Beitrag über MCP ohne Sitzung geht eine abgerissene Anfrage verloren, und die Wiederholbarkeit wandert aus dem Protokoll in die Anwendung.