n8n Loop Node (SplitLab)

1. Input: Ein Array mit 50 Items ([{name: "A"}, {name: "B"}, ...]).
2. Loop Over Items Node:
   • Batch Size: 1 (Verarbeite jeden einzeln).
3. Operation: "HTTP Request" (Sende an API).
4. Loop End: Verbinde den Ausgang des HTTP Request zurück zum Loop-Eingang? Nein! In n8n Version 1.0 gibt es einen speziellen Loop-Output. Nichts manuell verbinden! Der Node hat einen "Loop" Ausgang für die Schleife und einen "Done" Ausgang, wenn alles fertig ist.

1. Batch Size & Rate Limits

APIs erlauben oft nur 100 Requests pro Minute. Wenn du 1000 Items hast und Batch Size: 1 + Wait: 0s machst, wirst du geblockt (429 Too Many Requests). Lösung:

• Batch Size: 10
• Im Loop: "Verarbeite 10 parallel" (oder sequenziell).
• Am Ende des Loops: Wait Node (1 Sekunde). Das drosselt die Geschwindigkeit auf sichere 600/min.

2. State im Loop (Merging)

Ein Klassiker-Problem: Du willst Daten aus dem Loop sammeln ("Liste der erfolgreichen IDs"). Variable setzen (Set Node) im Loop überschreibt sich oft selbst oder ist außerhalb nicht sichtbar. Nutze den Code Node nach dem Loop, um $node['Loop'].json (Alle Iterationen) abzugreifen. n8n sammelt automatisch alle Resultate der Loop-Durchläufe im "Done"-Zweig.

3. Error Handling (Continue On Fail)

Wenn Item 50 von 100 fehlschlägt (API Down). Standardmäßig stoppt der ganze Workflow. 49 erfolgreich, 1 Fehler, 50 nicht bearbeitet. Setze in den Loop-Nodes (und den Nodes darin): "On Error: Continue". Dann läuft der Loop weiter. Du bekommst am Ende ein Array mit 99 Erfolgen und 1 Fehlerobjekt. Das musst du filtern.

Der Code-Node Bypass (State Aggregation)

Ein berüchtigtes Problem: Du durchläufst 100 PDFs, willst aber nicht 100 HTTP-Requests an eine Aggregations-API senden, sondern am Ende ein riesiges, gebündeltes JSON-Array ([ {pdf1}, {pdf2} ]) mit nur einem Schuss abfeuern. Wenn du dem "Loop" Ausgang folgst, hast du immer nur das aktuelle Item im Context. Die Profi-Lösung: Der "Done" (Fertig) Ausgang des Loop Nodes. Nach Abschluss aller 100 Zyklen wirft K8s/n8n das komplette verarbeitete Set exakt an diesem Pin ab. Ein nachfolgender Code-Node iteriert dann in Millisekunden über dieses Array (for (const item of $input.all())) und transformiert es in die massige Einzel-Payload.

Sub-Workflows vs. Loop (Memory Limits)

Der Loop Node stößt bei extremen Workloads (z. B. 50.000 CSV-Reihen) auf massive Grenzen der NodeJS V8 Engine (Heap Max 1.5GB). Jeder Loop-Umlauf pumpt den Execution-State weiter auf. Bei 50k Umläufen stürzt der Container mit SIGKILL OOM ab. Die architektonische Erlösung ist der Execute Workflow Node (Sub-Workflows). Statt einen Loop zu nutzen, jagst du das Array von 50.000 Items in diesen Node. Er "fanned" die Listen-Punkte aus und ruft für jedes Item einen winzigen, isolierten "Child-Workflow" auf. Da die Ausführung der Child-Workflows abgekoppelt an Node.js-Worker-Threads (oder via Redis an andere Container) delegiert und deren lokaler Scope nach dem Return sofort vom Garbage Collector geleert wird, skaliert dieser "Outsourced Loop" faktisch unendlich.

Exponential Backoff im Loop (API-Throttle)

Das statische Wait (Wait Node: 1s im Loop) ist in Firmen-Netzen oft verboten, da es die Ausführung linear verriegelt. Ein robustes Design nutzt Exponential Backoff. Schlägt die API im Loop (Item 54) mit Retry = True fehl, fängt ein Fallback-Pfad das Fehlerkonstrukt auf. Im Loop nutzt man eine Expression im Wait-Node: {{ Math.pow(2, $runIndex) * 1000 }} ms. Beim ersten API-Limit-Hit wartet die Schleife 2 Sekunden, dann 4, dann 8 und am Ende 16, bis die API das Token Bucket wieder freigibt. Dies ist "Resilience patterns for external integrations".