Merge node never executes after IF→Execute Workflow branch, despite correct item split — reproducible only in full 48-node graph, not isolated repro

[akibucs2112-hub]

Bug Description

A workflow with an IF node ("Route by Mascot") feeding two branches (one via Execute Workflow in fire-and-forget/integrated mode, one direct) into a Merge node ("Merge Mascot & Non-Mascot Branches", append mode) reliably fails to execute the Merge node. Execution reports lastNodeExecuted: "Route by Mascot", status success, no error, and the correct [2,0] item split on the IF node — but Merge never fires and nothing downstream runs. Completes in ~200-250ms (not a timeout/hang).

To Reproduce

• Deterministic across 5 real attempts on the live 48-node workflow (execution IDs 1272, 1293, 1296, 1299) and 1 full verbatim clone (1305).
• An isolated repro using byte-for-byte identical copies of the exact IF → Execute Workflow → Merge node combination completes successfully in <30ms — it does NOT reproduce the bug.
• The bug only reproduces when the full 48-node graph is present. Bisecting the graph down to a minimal repro has not yet succeeded — individually restoring each remaining untested piece (a second IF node gating mascot logic, two Generate Image nodes, an unused Manual Trigger branch) does not reproduce it alone.

Expected behavior

The Merge node should execute and pass data through once its immediate upstream (Route by Mascot) has reported success with the correct item split, matching the isolated repro (which merges successfully in <30ms with the identical IF → Execute Workflow → Merge node combination).

Ruled out:

• Merge waiting on a fully-skipped branch forever
• alwaysOutputData as workaround
• Random/transient failure (fully deterministic across 5 real runs + 1 clone)
• Task Runner acknowledgment timeout (a real "Runner took too long to acknowledge" log line was found, but the failure is ~200ms, far faster than the ~60s timeout window)
• Node-combination-specific bug (isolated verbatim repro works fine)
• Timing/ordering race (inserting a diagnostic NoOp node mid-edge didn't change the outcome)

Question: Is there a known execution-planning behavior tied to overall graph size/shape (e.g. diamond convergence patterns, or how expected-input counts are computed for Merge nodes) that could cause a Merge node to be silently marked as skipped in a large graph despite its immediate upstream reporting success?

Debug Info

Debug info

core

• n8nVersion: 2.27.4
• platform: docker (self-hosted)
• nodeJsVersion: 24.16.0
• nodeEnv: production
• database: sqlite
• executionMode: regular
• concurrency: -1
• license: enterprise (production)
• consumerId: 2132f95c-3a66-4de5-ad7d-106c936c1b60

storage

• success: all
• error: all
• progress: false
• manual: true
• binaryMode: filesystem

pruning

• enabled: true
• maxAge: 336 hours
• maxCount: 10000 executions

client

• userAgent: mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/151.0.0.0 safari/537.36
• isTouchDevice: false

security

• secureCookie: false

cluster

• instanceCount: 1
• versions: 2.27.4
• instances:
  • instanceKey: 92a7fc5b-e343-43d8-a1b5-f45240c863c4, hostId: main-e736526321ae, instanceType: main, instanceRole: leader, version: 2.27.4
• checks:
  • check: hostid-clash, status: succeeded, warnings: -
  • check: lifecycle, status: succeeded, warnings: -
  • check: split-brain, status: succeeded, warnings: -
  • check: version-mismatch, status: succeeded, warnings: -

Generated at: 2026-09-04T21:17:22.720Z

Operating System

Win 10 IOT LTSC running WSL/docker/n8n

n8n Version

2.27.4 (please confirm — unverified)

Node.js Version

24.18.0

Database

SQLite (default)

Execution mode

main (default)

Hosting

self hosted

[n8n-assistant]

Hey @akibucs2112-hub,

Thank you for reaching out! We’ve received your issue and are looking into it. To help us track this internally, we’ve created a Linear ticket with the reference: "GHC-9415".

We’ll keep you updated as we make progress, but if you have any additional details or context to share, feel free to add them here - it’s always helpful!

Thanks for your patience and for bringing this to our attention.

---

For INTERNAL use only: GHC-9415