Merge Node (Der Reißverschluss)

Er hat zwei Eingänge. Modi:

1. Append: Einfach alles hintereinander hängen (Erst Input 1, dann Input 2).
2. Wait: Warte, bis BEIDE Eingänge fertig sind, bevor es weitergeht. (Wichtig bei paralleler Verarbeitung).
3. Merge by Key: Verbinde Daten, die zusammengehören (z.B. Kundeninfo aus Datenbank A mit Bestellung aus Shop B anhand der E-Mail-Adresse verknüpfen).

Praxisbeispiel: Liste A enthält Kunden, Liste B enthält Bestellungen. Zusammengeführt wird über customer_id. Ohne gemeinsamen Schluessel entsteht schnell falsche Zuordnung.

Praxisroutine

In der Praxis lernst du Merge Node (Der Reißverschluss), indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

Achtung beim Wait Mode: Wenn einer der Eingänge nie Daten liefert (z.B. weil ein IF-Filter alles rausgefiltert hat), bleibt der Merge Node für immer stehen (oder bis zum Timeout). Er braucht auf beiden Leitungen ein Signal "Ich bin fertig" (auch wenn es ein leeres Signal ist).

Technisch musst du wissen, ob nach Position, nach Schluessel oder als Kombination gemerged wird. Fehlende Datensätze brauchen eine bewusste Regel, sonst verschwinden Informationen unbemerkt.

Technische Einordnung im System

Technisch ist Merge Node (Der Reißverschluss) nicht isoliert. Es wirkt mit Nachbarbegriffen zusammen, hat Voraussetzungen und erzeugt Folgen. Für ein robustes Verständnis prüfst du drei Fragen: Welche Daten oder Bedingungen braucht dieser Schritt? Welche Ausgabe oder Wirkung entsteht? Was passiert bei falschen, fehlenden oder zu großen Eingaben?

Diese Sicht ist wichtig, weil echte Systeme selten am Hauptpfad scheitern. Sie scheitern an Randfällen, Berechtigungen, Zeitpunkten, Formaten, Reihenfolgen oder stillen Annahmen.

SQL-Style Joins

Der "Merge by Key" Modus entspricht SQL Joins:

• Inner Join: Nur Datensätze, die in beiden Inputs einen Match haben (Key A == Key B).
• Left Join (Keep Everything): Alle Datensätze von Input 1 behalten, und wenn möglich mit Input 2 anreichern. Wenn kein Match, bleiben die Felder leer.

Multiplexing (Cartesian Product)

Wenn du Input 1 (3 Items) und Input 2 (3 Items) hast und "Merge by Position" machst, bekommst du 3 Items (1-1, 2-2, 3-3). Wenn du aber "Multiplex" wählst, bekommst du 3x3 = 9 Kombinationen. Jedes Item von A wird mit jedem Item von B kombiniert. Nützlich für: "Sende JEDE dieser 5 E-Mails an JEDEN dieser 100 User".

Datenanreicherung (Enrichment)

Typisches Pattern:

1. Liste von User-IDs (Input 1).
2. HTTP Request an CRM um Details zu holen (Input 2).
3. Merge Node (by ID): Kombiniert die User-ID mit den CRM-Daten zu einem vollständigen Objekt.

Der Wait-Modus als DAG-Synchronisation

n8n baut auf einem Directed Acyclic Graph (DAG) auf. Wenn sich der Flow splittet ("Parallele Ausführung"), operiert n8n nicht zwingend in echtem Multi-Threading. Die Ausführung springt sequenziell zwischen den parallelen "Zweigen" hin und her (Node-by-Node). Wenn du einen Wait Modus im Merge nutzt, friert der Merge-Knoten seinen Zustand ein. Er puffert die Hereinkommenden Items von Ast A auf der SSD/Memory und blockiert streng, bis das exakt gleiche Execution-Run-Id Event von Ast B aufschlägt. Handelt es sich um tausende Bulk-Items, kann das massive I/O und Memory-Auslastung auf dem n8n-Container bedeuten!

Wait vs. Append (Index-Matching Limits)

Nutzt du den Merge-Node zum simplen "Hinzufügen" nach einer Verzweigung (Output von A und Output von B als eine gemeinsame Liste an C senden), wählst du "Append". Nutzt du aber den klassischen SQL-Left-Join, musst du bedenken, dass die internen Item-Indizes (Index 0, 1, 2) das JSON anreichern. Tückisch wird es, wenn Ast A 5 Items liefert und Ast B nur 2. n8n verknüpft per Index Item 0 mit Item 0, Item 1 mit Item 1. Array B hat aber kein Item 2, 3 und 4. Ergebnis: Diese letzten drei Datensätze von A fließen un-joined und oft kaputt weiter. Deswegen ist "Merge by Key" (anhand eines Primärschlüssels wie E-Mail oder ID) in 99% aller Enterprise-Workflows die einzig valide Wahl, niemals "By Index".

Filter-Bypass und Fake-Signale

Ein klassischer Dead-Lock-Bug in Automatisierungen: Workflow teilt sich in Zweig A (zieht CRM-Daten) und Zweig B. In Zweig B prüft ein IF-Node "Preis > 1000". Nur wenn True, formatiere Text und gehe zum Merge-Node. Wenn das Item aber 500€ kostet, schluckt der IF-Node das Paket. Es kommt auf Zweig B am Merge-Node niemals etwas an. Der Merge-Knoten im Wait-Modus wird auf Zweig B bis in alle Ewigkeit warten. Der Workflow hängt als "Running" in den Executions fest, bis das harte DB-Timeout zuschlägt. Lösung: Um parallele Branches synchron zu halten, darf der Zweig nicht einfach sterben. Du musst den False-Output des IF-Nodes überflüssig patchen (dummy Node oder direkter Link an den Merge), um den Takt-"Tickereffekt" (Empty Item) an den Merge zu übermitteln, damit der Algorithmus entsperrt.