Schedule Trigger stoppt nach mehreren Tagen stillschweigend (Kubernetes + Queue-Modus)

Fragen
1

Beschreiben Sie das Problem/den Fehler/die Frage

Ich habe einen Workflow, der einen Schedule Trigger verwendet und mehrmals täglich ausgeführt wird. Nach mehreren Tagen, in denen alles korrekt funktionierte, wird der Workflow einfach nicht mehr ausgelöst. Es gibt keine fehlgeschlagenen Ausführungen und keine Fehlermeldungen in den Protokollen. Der Workflow bleibt aktiv, aber die geplanten Ausführungen starten nicht mehr.

Bei der Fehlerbehebung habe ich festgestellt, dass der Workflow weiterhin funktioniert, wenn ich die Anzahl der geplanten Ausführungen pro Tag reduziere — allerdings nur noch für einige weitere Tage, bevor er wieder stoppt. Das lässt mich vermuten, dass das Problem mit dem Scheduler, dem Queue-Modus oder einer Ressourcenbeschränkung zusammenhängt, die sich im Laufe der Zeit ansammelt.

Hat jemand erlebt, dass Schedule-Trigger-Workflows in einer Kubernetes-Bereitstellung im Queue-Modus stillschweigend stoppen?

Wie lautet die Fehlermeldung (falls vorhanden)?

Es gibt keine Fehlermeldung. Der Schedule Trigger wird einfach nicht mehr ausgelöst.

Bitte teilen Sie Ihren Workflow mit

Das Problem ist nicht spezifisch für einen bestimmten Workflow. Es tritt bei Workflows auf, die mit einem Schedule Trigger beginnen und erfolgreich ausgeführt werden, bis der Trigger aufhört zu werden ausgelöst.

Schedule Trigger → (verschiedene Knoten)

Geben Sie die Ausgabe des letzten Knotens an

Es gibt keine Ausgabe, wenn das Problem auftritt, da der Workflow nie startet. Wenn er ausgeführt wird, wird der Workflow erfolgreich abgeschlossen.

Informationen zu Ihrem n8n-Setup

  • n8n-Version: Helm-Chart n8n Version 1.16.39 (teilen Sie mir bitte mit, wenn die eigentliche Anwendungsversion relevanter ist)
  • Datenbank: PostgreSQL (extern)
  • n8n EXECUTIONS_PROCESS-Einstellung: Queue-Modus
  • n8n wird ausgeführt über: Kubernetes mit dem Community Helm Chart
  • Betriebssystem: Kubernetes-Cluster (Linux-Knoten)

Relevante Konfiguration

redis:
  enabled: true

worker:
  mode: queue

webhook:
  mode: queue
  url: https://<my-domain>

db:
  type: postgresdb

externalPostgresql:
  host: <external-postgres>

Weitere Beobachtungen:

  • Die Workflows stoppen ohne Fehler oder fehlgeschlagene Ausführungen.
  • Die Reduzierung der Anzahl der geplanten Ausführungen pro Tag verzögert das Problem, behebt es aber nicht.
  • Ein Neustart der Bereitstellung stellt den Schedule Trigger vorübergehend wieder her.
  • Redis ist aktiviert und PostgreSQL ist extern.

Könnte dies mit dem Queue-Modus, der Leader-Election oder dem Scheduler-Prozess in einer Multi-Pod-Kubernetes-Bereitstellung zusammenhängen?

2

Hallo @thun

Es gibt ein dokumentiertes Problem (referenziert in GitHub Issues #30220 und #30256), bei dem der Schedule Trigger nach einer bestimmten Anzahl von Ausführungen stillschweigend nicht mehr auslöst (oft nach etwa 700+ Ticks bei hochfrequenten Workflows).

  • Das Symptom: Der Workflow bleibt in der Benutzeroberfläche auf „Aktiv
3

Danke für die Antwort!

Ich habe mir die Hauptpod-Protokolle angesehen und sah viele „Maximum call stack size exceeded

4

Gut, dass du den ‘Maximum call stack size exceeded’-Fehler bestätigt hast – das ist der Bug aus #30220. Eine Sache, die du in deinen Helm-Werten vor und nach dem Upgrade doppelt überprüfen solltest: replicaCount für das Haupt-Deployment muss genau 1 sein. Das Ausführen von mehr als 1 Haupt-Replik verursacht Scheduler-Registrierungskonflikte in Redis, die dasselbe Silent-Stop-Symptom auch nach dem Upgrade reproduzieren können. Worker können frei skaliert werden, aber das Haupt-Deployment bleibt bei 1.

5

Freut mich, dass das Log-Grep das bestätigt hat — ein ganzes Meer von „Maximum call stack size exceeded

6

Eine letzte Anmerkung, bevor dieser Thread geschlossen wird, denn es gibt ein Kubernetes-spezifisches Detail, das die obigen Lösungen nicht abdecken, und es erklärt, warum dieser Fehler in deinem Cluster besonders still abläuft.

Deine Liveness Probe kann diesen Fehler nicht erkennen. Der n8n Health Endpoint antwortet vom Webserver, und der Webserver funktioniert einwandfrei, während die Scheduler Loop steckenbleibt. Kubernetes meldet daher weiterhin einen gesunden Pod und startet ihn nie neu. Das ist der Grund, warum der Ausfall tagelang andauert: Der einzige Mechanismus, der einen defekten Pod neu starten soll, liest ein Signal, das die defekte Komponente gar nicht abdeckt. Prozessintegrität und Scheduler-Integrität sind unterschiedliche Dinge, und jede Probe, die du derzeit hast, misst nur die erste.

Da ein Neustart den Trigger zuverlässig wiederherstellt, kannst du die Lücke überbrücken, während du das Update planst, mit einem Canary: Ein triviales geplantes Workflow, das nichts anderes tut, als alle paar Minuten einen Zeitstempel irgendwo günstig zu schreiben – ein Redis-Schlüssel, eine Postgres-Zeile oder ein Ping zu einem kostenlosen Monitor wie Healthchecks.io. Wenn der Zeitstempel veraltet ist, ist die Scheduler unabhängig davon, was der Health Endpoint sagt, steckengeblieben. Wenn du es vollständig automatisieren möchtest, ein kleiner CronJob, der die Frische des Canary prüft und einen Rollout-Neustart der Hauptbereitstellung durchführt, wenn er veraltet ist, verwandelt einen mehrtägigen Ausfall in wenige Minuten Störung – ein akzeptabler Übergangslösung für einen Fehler, den nur das Update wirklich behebt.

Zwei Checks, die beim nächsten Steckenbleiben sinnvoll sind, vor dem Neustart, damit die Update-Entscheidung auf Fakten basiert. Schnapp dir die Hauptpod-Logs und suche nach RangeError: Maximum call stack size exceeded, wie kjooleng sagte. Und mach die Tick-Mathematik: Deine eigene Beobachtung, dass weniger Läufe pro Tag den Fehler verzögert, ist genau das, was ein Ticks-Schwellenwert-Bug vorhersagt. Wenn also Läufe pro Tag multipliziert mit Tagen bis zum Fehler über deine Vorfälle hinweg ungefähr konstant ist, hast du die Bestätigung, ohne auch nur auf die Log-Zeile warten zu müssen.