Hallo zusammen!
Ich betreibe n8n 2.21.7 im Queue-Modus (EXECUTIONS_MODE=queue) mit
PostgreSQL und Redis, gehostet auf Easypanel mit Docker.
Ich habe einen Workflow mit einem Form Trigger mit responseMode auf
„lastNode
dieser „Cannot read properties of undefined (reading ‘execute’)
Hallo @ricardo_balako
Der Fehler, den du erhältst – „Cannot read properties of undefined (reading ‘execute’)
Willkommen @ricardo_balako!
Die Grundursache liegt hier in der Architektur: Form Trigger mit responseMode=lastNode erfordert, dass der Haupt-n8n-Prozess die HTTP-Verbindung offen hält, bis der Workflow abgeschlossen ist. Im Queue-Modus wird die Ausführung an einen Worker übergeben - und diese offene Verbindung kann nicht über die Prozessgrenze hinweg mitfolgen. Der Queue.onFailed in deinem Stack Trace bestätigt, dass der Job auf Queue-Ebene abbricht, bevor überhaupt ein Node startet.
Die schnellste Lösung ist das, was achamm vorgeschlagen hat - ändere „Respond When
Es ist sinnvoll zu bestätigen, was bereits angedeutet wurde: Dies ist ein bekannter n8n-Bug bei Form-/Webhook-Style-Triggern im Queue-Modus, nicht etwas, das in deinem Workflow falsch läuft. Es funktioniert im Editor, weil die manuelle Ausführung im Hauptprozess läuft, und schlägt auf der Produktions-URL fehl, weil im Queue-Modus ein Worker es aufgreift und der Trigger-Kontext nicht auf die gleiche Weise verbunden ist.
Praktische Lösungswege bis zur Behebung upstream: Wenn dieser eine Workflow die Skalierung des Queue-Modus nicht benötigt, führe ihn im normalen (Haupt-)Ausführungsmodus aus und nutze Queue-Modus nur für die ressourcenintensiven Workflows. Wenn alles im Queue-Modus laufen muss, ist ein häufiger Workaround, es aufzuteilen: ein einfacher Webhook-Node, der den Form-Post empfängt (Webhooks verhalten sich besser als der Form Trigger im Queue-Modus), dann die Antwort separat behandeln, anstatt sich auf responseMode lastNode durch den Form-Node zu verlassen.
Da das zugehörige GitHub-Issue als „nicht geplant
Gelöst! So habe ich es hinbekommen:
Das Problem war genau das, was @kjooleng beschrieben hat — eine Versionsinkompatibilität zwischen meinen n8n-Diensten. Ich führe n8n auf Easypanel mit drei separaten Diensten aus: n8n_start, n8n_webhook und n8n_worker. Sie alle führten unterschiedliche Versionen des Docker-Images aus, was die Queue-Kommunikation zerstörte, bevor überhaupt ein Knoten ausgeführt wurde.
Die Korrektur war einfach: Ich habe alle drei Dienste auf denselben Tag latest aktualisiert und alle gleichzeitig erneut bereitgestellt. Danach funktionierte alles in der Produktion perfekt.
Haupterkenntnis: Wenn du n8n im Queue-Modus mit separaten Worker-/Webhook-Containern ausführst, stelle sicher, dass alle Dienste exakt die gleiche Version haben. Selbst ein kleiner Unterschied zwischen der Hauptinstanz und dem Worker reicht aus, um diesen Fehler auszulösen.
Danke an alle für die Hilfe!