Der n8n-Fallstrick, der 48 Artikel kostete

Ein Stapelauftrag über 51 Datensätze war nach acht Minuten fertig. Das klang nach einem guten Tag. Tatsächlich waren von 51 Ergebnissen drei angekommen.

Der Fehler steckt in einer Voreinstellung von n8n, die nirgends im Weg steht, bis sie es plötzlich tut. Wer Automatisierungen baut, die mehrere Datensätze auf einmal verarbeiten, läuft früher oder später hinein. Hier steht, woran man es erkennt und was dagegen hilft.

Der Auftrag

Der Workflow sollte 51 Blogartikel überarbeiten. Für jeden Artikel drei Schritte:

1. Text von einem Sprachmodell erzeugen lassen (über einen HTTP-Request-Knoten)
2. Ergebnis prüfen und eine Datei bauen (Code-Knoten)
3. Datei in ein Git-Repository schreiben (wieder HTTP-Request)

Ein linearer Ablauf, 51 Eingangs-Items, nichts Ungewöhnliches. Am Ende stand eine Bilanz, die die Zahl der erzeugten Artikel meldete.

Das Symptom: verdächtig schnell

Die Bilanz meldete 18 Artikel. Im Repository lagen drei.

Bevor ich in die Fehlersuche ging, fiel etwas anderes auf: Die Laufzeit passte nicht. Ein Modellaufruf dieser Größe dauert rund eine Minute. 51 Aufrufe nacheinander wären etwa eine Stunde gewesen. Der Lauf war nach acht Minuten durch.

Eine Zahl, die zu gut ist, ist ein Befund. Wenn ein Schritt mit vielen Datensätzen auffällig schnell fertig wird, arbeitet er sie nicht nacheinander ab.

Die Ursache

Der HTTP-Request-Knoten in n8n verarbeitet mehrere Eingangs-Items nebenläufig. Er wartet nicht, bis die Antwort auf Item 1 da ist, bevor er Item 2 losschickt — er schickt sie zusammen raus.

Für die meisten Anwendungsfälle ist das genau richtig und spart viel Zeit. In diesem Workflow führte es an zwei Stellen zu Datenverlust, und zwar aus zwei völlig verschiedenen Gründen:

Erstens beim Sprachmodell. 51 nahezu gleichzeitige Anfragen an denselben Anbieter lösten dessen Ratenbegrenzung aus. 33 Anfragen kamen ohne verwertbare Antwort zurück. Kein Absturz, keine Fehlermeldung im Log — nur Antworten ohne Inhalt.

Zweitens beim Schreiben nach Git. Hier lag der Knoten auf fünf gleichzeitigen Anfragen. Git-Server serialisieren Commits auf demselben Branch: Zwei Schreibvorgänge, die von derselben Ausgangsversion starten, können nicht beide gewinnen. Von 18 Dateien wurden drei angelegt, 15 kollidierten und gingen verloren.

Beide Fehler haben dieselbe Wurzel und sind doch verschieden: Einmal ist das Gegenüber überlastet, einmal ist der Vorgang seiner Natur nach nicht parallelisierbar.

Die Abhilfe

Der HTTP-Request-Knoten hat unter Options → Batching zwei Einstellungen:

"options": {
  "batching": {
    "batch": {
      "batchSize": 1,
      "batchInterval": 500
    }
  }
}

batchSize: 1 bedeutet: ein Item zur Zeit, echte Serialisierung. batchInterval legt die Pause zwischen zwei Stapeln in Millisekunden fest.

Beim zweiten Lauf mit dieser Einstellung: 48 Artikel, null Schreibfehler. Die Laufzeit stieg von acht auf zwölfeinhalb Minuten — und diese Verlangsamung war das Zeichen, dass es jetzt richtig lief.

Wo Serialisierung nötig ist, lässt sich vorher sagen. Immer dann, wenn

• gegen eine API mit Ratenbegrenzung gearbeitet wird,
• mehrere Vorgänge auf dieselbe Ressource schreiben (Git-Branch, Datei, Datensatz),
• oder die Reihenfolge inhaltlich eine Rolle spielt.

Überall sonst kann die Nebenläufigkeit bleiben, wo sie ist.

Der zweite Fehler, und der war meiner

Die Bilanz meldete 18 Artikel, während drei im Repository lagen. Dieser Unterschied war kein Folgefehler der Nebenläufigkeit, sondern ein eigener Denkfehler:

Der Auswertungsschritt zählte, wie oft das Sprachmodell brauchbar geliefert hatte — nicht, wie oft eine Datei tatsächlich geschrieben worden war. Er maß einen Zwischenschritt und meldete ihn als Ergebnis.

Das ist gefährlicher als der erste Fehler. Ein verlorener Datensatz fällt irgendwann auf. Eine Erfolgsmeldung, die den falschen Schritt misst, sorgt dafür, dass er eben nicht auffällt — und im konkreten Fall wurde auf Basis dieser Zahl eine Freigabe erteilt.

Die Korrektur: Ausgewertet wird nur noch, was der Zielserver bestätigt hat — also das Vorhandensein einer Commit-Kennung in der Antwort. Verworfene und fehlgeschlagene Schreibvorgänge werden getrennt ausgewiesen, nicht zusammengezählt.

Eine Erfolgsmeldung muss den letzten Schritt messen, nicht einen vorgelagerten. „Das Modell hat geliefert” ist nicht „die Datei ist geschrieben”.

Was beim Aufräumen half

Zwei Entwurfsentscheidungen haben den Schaden begrenzt und die Wiederaufnahme trivial gemacht.

Fehler einzelner Items dürfen den Lauf nicht kippen. Der Modellaufruf lief mit onError: continueRegularOutput. Ein misslungener Datensatz reißt damit die übrigen 50 nicht mit; er wird danach aussortiert und benannt. Ohne das wäre der erste Lauf beim ersten Ratenlimit-Fehler komplett abgebrochen.

Die Auswahl war eine Bedingung, keine Liste. Der Workflow suchte sich die zu bearbeitenden Datensätze über inhaltliche Merkmale zusammen, statt eine feste Liste abzuarbeiten. Ein bereits überarbeiteter Datensatz erfüllt die Merkmale nicht mehr und fällt beim nächsten Lauf von selbst heraus.

Das Ergebnis: Ein erneuter Lauf nahm genau die noch offenen Fälle — ohne Statusspalte, ohne Merkliste, ohne Sonderlogik. Von 51 blieben nach dem ersten Lauf 48 offen, nach dem zweiten zwölf, nach dem dritten keiner.

Wer Stapelaufträge baut, sollte diese Eigenschaft bewusst anstreben: Der Zustand soll aus den Daten ableitbar sein, nicht nebenher mitgeführt werden. Dann ist jeder Abbruch folgenlos.

Was offen blieb

Ehrlichkeitshalber: Die Ursache der Modell-Ausfälle ist nicht bewiesen. Das Muster spricht für eine Kontingentgrenze — die Fehler häuften sich am Ende eines Laufs und waren beim nächsten Lauf wieder verschwunden. Belegt ist das nicht, weil der Fehlerkörper der Antwort zwar im Item landete, aber nicht ausgewertet wurde.

Wer denselben Effekt sieht, sollte den Antwortkörper mit protokollieren. Beim Schreiben nach Git ist die Sache dagegen eindeutig: null Fehler nach der Umstellung, in mehreren Läufen.

Drei Regeln zum Mitnehmen

1. Miss die Laufzeit gegen deine Erwartung. Zu schnell ist ein Befund, nicht ein Erfolg.
2. Serialisiere, wo das Gegenüber es verlangt. Ratenbegrenzungen und gemeinsame Schreibziele vertragen keine Nebenläufigkeit — batchSize: 1 kostet Zeit und spart Daten.
3. Zähle das Ergebnis, nicht den Zwischenschritt. Sonst meldet die Automatisierung Erfolg, während nichts angekommen ist.

Der dritte Punkt ist der wichtigste, weil er der einzige ist, der ohne Zutun still bleibt. Die ersten beiden verraten sich irgendwann von selbst.

Dieser Artikel wurde KI-unterstützt erstellt und vor der Veröffentlichung geprüft.