Wir stoßen in n8n intermittierend auf den folgenden Fehler:
Problem executing workflow
There was a problem executing the workflow.
Regular expression execution timed out
Das Problem scheint nicht auf einen bestimmten Workflow oder Knoten beschränkt zu sein. Es tritt gelegentlich in mehreren nicht miteinander verbundenen Workflows auf.
Was wir beobachtet haben:
Der Fehler tritt intermittierend und nicht bei jeder Ausführung auf.
Er ist nicht auf einen spezifischen Workflow oder Knoten begrenzt.
Ein erneuter Versuch desselben Workflows ist manchmal erfolgreich.
Er scheint auch in Workflows aufzutreten, die nicht explizit reguläre Ausdrücke verwenden.
Wir haben noch nicht festgestellt, ob er mit gleichzeitigen Workflow-Ausführungen zusammenhängt.
n8n-Version: 2.36.7
Fragen:
Handelt es sich um ein bekanntes Problem in n8n oder einer seiner internen Abhängigkeiten?
Kann dieser Fehler auch auftreten, wenn ein Workflow nicht explizit reguläre Ausdrücke verwendet?
Welche Logging-Stufe oder Umgebungsvariablen sollten wir aktivieren, um die Quelle zu identifizieren?
Gibt es eine Möglichkeit, herauszufinden, welcher Ausdruck oder Knoten das Timeout des regulären Ausdrucks ausgelöst hat?
Könnte hohe Parallelität, CPU-Auslastung oder Speicherdruck diesen Fehler intermittierend verursachen?
Bitte teilen Sie uns mit, welche Protokolle, Stack Traces oder Diagnoseinformationen am hilfreichsten wären. Jede Anleitung von Nutzern, die ein ähnliches Problem erlebt haben, würde sehr geschätzt.
Bitte überprüfe, ob du N8N_EXPRESSION_ENGINE auf vm gesetzt hast. Das ist der einzige Pfad, bei dem ein Ausdruck unterbrochen wird, da die standardmäßige Legacy-Engine sie ohne Isolation und ohne Timeout ausführt, und vm ist in der Dokumentation noch als experimentell gekennzeichnet.
Das Zufällige ergibt sich aus N8N_EXPRESSION_ENGINE_POOL_SIZE, die standardmäßig auf 1 gesetzt ist. Jeder Ausdruck auf der gesamten Instanz wartet in einer Warteschlange für diesen einen warmen V8-Isolat gegen eine 5000-ms-Wanduhr, also kann unter Concurrency ein trivialer Ausdruck in einem beliebigen Workflow das Budget sprengen. Das ist dein Intermittent, deine unabhängigen Workflows und deine bestandenen Wiederholungen. Erhöhe die Pool-Größe und N8N_EXPRESSION_ENGINE_TIMEOUT, oder setze die Engine zurück auf Legacy, um es nach einem Neustart auszuschließen.
Hi @a2sembly Willkommen!
Dieser String stammt aus dem ReDoS-Guard, den n8n-workflow in 2.35 hinzugefügt hat. Er führt jeden Regex in einem node:vm-Skript mit einem 250-ms-Timeout aus. Das Budget ist Wanduhrzeit und nicht CPU-Zeit, daher muss der Prozess nur kurzzeitig die CPU verlieren – durch gleichzeitige Ausführungen, ein Container-CPU-Kontingent oder eine Garbage-Collection-Pause – damit ein günstiges Muster es überschreitet und ein Retry durchgeht.
Es wird in Workflows ausgelöst, die kein eigenes Regex enthalten, da derselbe Guard auch Anzeigebedingungen von Knotenparametern, Parametervalidierung, IF- und Filter-Bedingungen sowie Ausdrucksauflösung unterstützt. Es sitzt außerhalb der Ausdrucksmaschine, daher gilt es bei der Standardeinstellung legacy, und die 250 ms sind hartcodiert ohne Umgebungsvariable zum Erhöhen – noch immer hartcodiert im 2.37-Beta.
Der Hebel ist CPU-Headroom. Wenn du selbst gehostet hast, begrenze gleichzeitige Ausführungen, damit sie nicht konkurrieren, und erhöhe dann das Limit von dort aus:
Die Ursache und die oben erwähnte Concurrency-Fix sind genau richtig, daher werde ich einfach den Teil hinzufügen, den die Fragen 3 und 4 wirklich verfolgten: wie man den Schuldigen findet, und wie man verhindert, dass ein intermittierender Fehler dir stillschweigend einen Durchlauf kostet.
Um es zu lokalisieren, setze N8N_LOG_LEVEL=debug, damit der fehlgeschlagene Node und die Execution-ID in den Logs angezeigt werden, und leite jeden kritischen Workflow an einen zentralen Error Trigger-Workflow weiter, der die Execution-ID, den Workflow-Namen und den letzten Node in ein Sheet oder eine Tabelle aufzeichnet. Da dies intermittierend über viele unabhängige Workflows hinweg auftritt, verwandeln ein paar Tage dieser Logs „zufällig überall