Gibt es eine Grenze für Sub-Workflows in einer n8n-Pipeline?

Fragen
1

Describe the problem/error/question

My pipeline is made of several webhook triggers and several schedule triggers, plus around 15 nested sub-workflows (called through Execute Workflow).

Recently I wanted to set up a dev environment. I cannot point my webhooks at a separate dev target, so the best idea I came up with was to copy the whole pipeline and wire the copy into the main one through an IF node and a global variable dev: on/off. When dev is on, every incoming payload is duplicated and also pushed to the dev copy through a webhook. When dev is off, only prod runs. The goal was to test the exact same real data that hits prod, but on the dev copy, and once something works there, move it to prod. This matters because, as I said, I have around 15 nested sub-workflows, so I really want to validate changes on real traffic before promoting them.

After I connected the dev copy to prod, I started getting strange problems that I never had before:

  • Some sub-workflows that were clearly published in the main workflow started throwing errors like “unpublished sub-workflow”. That made no sense to me, they were published.
  • I started getting race condition problems on basically every node that touches the n8n Data Tables / built-in DB.

Deleting the dev pipeline made all of this go away immediately.

So I have two questions:

  1. If n8n started behaving like this (false “unpublished sub-workflow” errors and race conditions) just from roughly doubling the number of sub-workflows and executions, should I be worried that simply growing my normal prod with more nested sub-workflows over time will trigger the same bugs? Is there a known limit or known issue around the number of nested sub-workflows or concurrent executions on the Pro plan?
  2. What is the recommended way to build a dev environment in my situation? I cannot easily repoint the webhooks, I have many nested sub-workflows, and I want to test against the same real data that prod receives.

What is the error message (if any)?

“unpublished sub-workflow” on sub-workflows that are actually published, plus intermittent race condition errors on nodes using the n8n Data Tables.

Share the output returned by the last node

(the failing sub-workflow call returns the "unpublished sub-workflow" error instead of running)

Information on your n8n setup

  • n8n version: 2.25.7
  • Database (default: SQLite): default n8n
  • n8n EXECUTIONS_PROCESS setting (default: own, main): default (n8n Cloud managed)
  • Running n8n via (Docker, npm, n8n cloud, desktop app): n8n Cloud
  • Operating system: n8n Cloud
  • Plan: Pro, around 30k executions/month
2

Hallo @pohgen

Da du über 15+ verschachtelte Workflows verfügst und Race Conditions beobachtest, bist du aus dem “Single-Instance”-Ansatz für die Entwicklung herausgewachsen.

Der Gold Standard für n8n ist eine komplett separate n8n-Instanz für Dev. Da du die Webhook-Quelle nicht ändern kannst, nutze deine Prod-Instanz als „dummen Proxy

3

Hallo @koushikromel

Ich hatte eine Dev-Pipeline genau wie du erwähnt hast: Bei jedem Trigger hatte ich einen Node mit if/else, der eine globale Variable (dev: on/off) überprüft, und dann einen HTTP POST Node, der die Daten an die Dev sendet (passed). Mit dem Verständnis, dass diese Logik potenziell keine Ressourcen überlasten sollte, bin ich immer noch auf unerwartet Verhalten seitens n8n gestoßen. Vielleicht hat n8n Ressourcenlimits, wenn es von der Cloud gehostet wird?

4

hi @pohgen

um deine spezifischen Fragen zu beantworten:

  1. Es gibt keine dokumentierte harte Obergrenze für Sub-Workflows. Das Problem, auf das du gestoßen bist, hat nichts mit der Anzahl zu tun, sondern mit SQLite und Parallelität. Deine Cloud-Instanz verwendet standardmäßig SQLite, und SQLite hat eine Single-Writer-Sperre. Als du deine Pipeline verdoppelt hast, schrieben sowohl die prod- als auch die dev-Kopie gleichzeitig in die gleichen Data Tables, was zu Schreibkontention führte. Die Fehler „unpublished sub-workflow
5

@pohgen gute Nachricht: Es gibt keine harte Grenze für verschachtelte Sub-Workflows, das Wachstum von Prod triggert das nicht. Auf Cloud zählt Concurrency (Pro = 50) nur Webhook-/Trigger-Ausführungen, nicht Execute Workflow Aufrufe, also verbrauchen mehr verschachtelte Sub-Workflows dein Budget nicht.

Was es kaputt gemacht hat, war das Klonen der Pipeline in die gleiche Instanz: die “unpublished sub-workflow” Fehler sind Prod- und Dev-Kopien, die kollidieren (doppelte Sub-Workflows lassen Execute Workflow die falsche/unveröffentlichte Kopie treffen), die Data Table Races sind beide Kopien, die gleichzeitig auf die gleichen Built-in-Tabellen zugreifen, und du hast die Webhook-Ausführungen verdoppelt, die auf das 50er-Cap angerechnet werden. Die Dev-Kopie, deren Löschen alles behebt, bestätigt, dass es die Duplizierung ist, nicht die Anzahl.

Für Dev: Nutze eine separate n8n-Instanz mit ihren eigenen Data Tables, damit sie nicht mit Prod konkurriert. Um echte Daten zu testen, ohne Webhooks umzuleiten, erfasse die Prod-Payloads und spiele sie in Dev ab, statt Live-Traffic zu splitten.