Ich habe ein Problem, bei dem sich ein Workflow mit einem Email Trigger (IMAP)-Knoten sofort selbst deaktiviert, wenn ich versuche, ihn einzuschalten, und wirft einen WorkflowActivationError, der vom Error Trigger des Workflows abgefangen wird.
Aber die manuelle Ausführung funktioniert perfekt ohne Fehler.
Fehlerdetails (abgefangen vom Error Trigger):
[
{
"trigger": {
"error": {
"message": "There was a problem with the trigger node \"Email Trigger (IMAP)\", for that reason did the workflow had to be deactivated",
"timestamp": 1785767782822,
"name": "WorkflowActivationError",
"context": {}
},
"mode": "trigger"
},
"workflow": {
"id": "zTAdqKiYBPODh3yr",
"name": "03.03. Яндекс -> amoCRM (deleted@pioneercert.ru)"
}
}
]
Hi @Sokol
WorkflowActivationError ist der Wrapper, den n8n an den Error Trigger übergibt, wenn ein Trigger-Knoten fehlschlägt. Trigger-Knoten-Fehler kommen immer mit context: {} und ohne Cause an, sodass der echte IMAP-Fehler die UI nie erreicht und stattdessen ins Instance-Log geht. Manuelle Läufe führen einen einzelnen Fetch und Close durch, Aktivierungen halten die Verbindung offen, weshalb nur die Aktivierung den Fehler auslöst. Schalte den Workflow ein und lese das Log direkt danach:
Wir haben das überprüft und es sieht so aus, als könnte es in einem neueren Release behoben sein. Bitte aktualisieren Sie und schauen Sie, ob das Problem immer noch auftritt.
Hallo,
Immer noch auf 2.33.3, gleiches ECONNRESET/EPIPE-Muster wie vor dem Update, keine Änderung.
Eine Sache, die mir aufgefallen ist: Es ist nicht auf ein Postfach beschränkt, mail@, deleted@ und notification@ auf demselben VPS fallen alle zur gleichen Zeit im selben engen Systemloop aus. Das ließ mich fragen, ob dies wirklich eine Sache der Netzwerkebene ist und nicht etwas, das Yandex oder n8n pro Konto tut. Wie die VPS-Firewall oder die Conntrack-Tabelle, die untätige Verbindungen abbricht, bevor n8n eine Chance hat, sich erneut zu verbinden.
Ich habe die Conntrack-Timeout noch nicht überprüft, werde ausführen
sysctl net.netfilter.nf-conntrack-tcp-timeout-established und den Wert posten. Ich werde auch überprüfen, auf welche Werte Force Reconnect derzeit auf diesen Knoten eingestellt ist, da ich nicht sicher bin, ob es überhaupt konfiguriert ist.
Warum stimmt die 15-Minuten-Einstellung nicht mit dem überein, was ich im Log gesehen habe?
Ich schätze, dass du es geteilt hast. Ein Punkt fällt auf: Obwohl Force Reconnect auf 15 Minuten eingestellt ist, traten die ECONNRESET/EPIPE-Probleme laut dem Log, das du zuvor gegeben hast, Rücken an Rücken in einer engen Schleife auf, anstatt ungefähr alle 15 Minuten. Du würdest erwarten, dass Fehler etwa 15 Minuten auseinander verteilt auftreten, anstatt eines plötzlichen Anstiegs, wenn Force Reconnect der Verursacher wäre. Daher ist diese Option höchstwahrscheinlich nicht der Hauptgrund; die Verbindung wird viel früher als die zugeteilten 15 Minuten beendet.
Es lohnt sich zu überprüfen, ob die Werte der anderen Postfächer (mail@, notification@) gleich sind oder ob einer anders eingestellt oder nicht gesetzt ist. Das würde es leichter machen zu bestimmen, ob es eine knotenbezogene Konfiguration ist oder etwas, das sie alle gleich beeinflusst.
Plane immer noch, den conntrack-Timeout zu überprüfen, werde diesen Wert posten, sobald ich ihn habe – das ist das Stück, das uns tatsächlich sagen wird, ob dies das VPS/die Firewall oder etwas bei der Reconnect-Handhabung von n8n ist.
Falls du zusätzliche Daten brauchst oder ich dir das Falsche geschickt habe, sag mir Bescheid. Ich schicke dir gerne die zusätzlichen Informationen, damit wir eine Lösung finden können.
Führe docker logs n8n-n8n-worker-1 2>&1 | grep -i imap aus und schaue, was zurückkommt. Teile mir die Ergebnisse mit.
Außerdem, auf welchen Wert EXECUTIONS_MODE gesetzt ist (oder ob du N8N_DISABLE_PRODUCTION_MAIN_PROCESS verwendest).
Stelle auch die Worker-Log-Ausgabe aus dem gleichen Zeitfenster wie einer der Fehler in deinem docker ps/Log-Screenshot zur Verfügung, damit die Zeitstempel tatsächlich gegen die Hauptprozess-Fehler abgeglichen werden können.
ob dieser LOGIN-Fehler wiederholt über die verschiedenen Mailboxen hinweg auftritt, und ob die Zeitstempel dicht beieinander liegen – wenn mehrere Mailboxen in derselben Domain/IP alle LOGIN um die gleichen Momente herum wiederholen, sieht es so aus, als würde Yandex’ Missbrauchsschutz/Rate-Limiting durch wiederholte Login-Versuche von einer VPS-IP aus aktiviert, nicht um ein Pro-Konto-Problem.
Mein Vorschlag:
der sc= Code ist ein Yandex-seitiger Trace-/Support-Identifikator, es lohnt sich, diesen direkt an den Yandex-Support zu übermitteln, da wenn dies Rate-Limiting ist, es nichts ist, das sich rein von der n8n-Konfigurationsseite aus beheben lässt.
