Ghost sub-executions: duplicated runs while parent execution shows single calls

Hey, we’re facing a major issue with nodes being triggered twice, even though the execution log shows only one execution. This has been happening for a few weeks now, but it’s difficult to pinpoint when it started.

Here’s a concrete example with the sub-execution node, but the problem seems to affect all nodes that trigger other tools (or maybe all nodes?).

My parent workflow was executed once on 2025-09-12 (execution id: 12464199):

In this same workflow, I’m calling a sub-workflow 20 times with 100 items each, as shown in the parent workflow:

BUT: the sub-workflow executions are duplicated, resulting in 40 sub-executions

All the duplicated sub-executions aren’t listed in the parent node, while the parent execution does appear in the duplicated sub-executions:

Our guess is that this could be related to our architecture, since the instance is distributed across 2 workers. However, the execution logs of the parent workflows only show one call, so we’re not sure how to proceed.

This problem persists across the versions we’ve recently upgraded through.

Information on your n8n setup

  • n8n version: 1.109.2
  • Database (default: SQLite): using RDS Postgres and EFS for storing n8n data
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): self-hosted mode on aws with Fargate (docker)
  • Operating system:

@theo the duplicate sub-workflow runs you’re seeing match a known issue in queue mode with multiple workers. Community reports confirm that sub-workflows (especially when combined with Wait/Webhook nodes) can be picked up by more than one worker, creating “ghost” executions linked to the same parent ID. With a single worker the problem usually disappears.

To validate: run the same workflow with only one worker and check if duplicates stop. Also review the Execute Sub-workflow settings (run once per item vs all items) and check your logs for multiple “enqueue” events around the same execution ID. This is not caused by your workflow design but by a race condition in n8n’s distributed execution.

Hello @Gallo_AIA

Many thanks for confirming it’s coming from the 2 workers.

Would you have any idea if this is something that should be fixed soon? I feel like it’s a flaw in the product, but I didn’t find reports, communications, or documentation about this.

Thank you again.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.