Sub-workflow execution starts but no nodes run (0 ms, empty runData) — n8n 2.20.7-exp.0

Context

I have a chain of 3 n8n workflows :

  • main — generates combinations, loops, calls intermediaire per item
  • intermediaire — receives items via Execute Workflow Trigger, batches them via Loop Over Items, calls sub/sub per batch via an Execute Workflow node
  • sub/sub — receives items via Execute Workflow Trigger, processes them through Code → Convert to File → Gemini → Formatter → Airtable Create

The chain main → intermediaire works fine. The chain intermediaire → sub/sub does not.

Symptom

When intermediaire calls sub/sub, an execution for sub/sub is created (visible in the Executions tab, status: success, mode: integrated), but :

  • duration : ~20 ms
  • runData : empty {} (no node executed, not even the trigger)
  • nodeExecutionStack : empty
  • yet the Execute Workflow node in the parent shows 1 item in its output

Running sub/sub manually with pinned data works perfectly (~3.5 s, all nodes execute as expected). The bug only happens when it’s called from the parent.

What I’ve tried

  1. Disabled the typed input schema on the sub/sub trigger (inputSource: "passthrough") → still empty.
  2. Deleted and recreated the Execute Workflow Trigger node → same result.
  3. Upgraded n8n to the latest version → same result.
  4. Patched the workflow JSON directly via REST API to force inputSource: "passthrough" and remove an events field that I initially suspected (typo "worklfow_call"). The API GET returns the cleaned version, but the execution snapshot still embeds the old/buggy parameters — meaning the engine reads from a stored copy that diverges from what I PUT.
  5. Verified that the snapshot of the sister workflow intermediaire (which works) has the exact same internal value events: "worklfow_call" — so that field is not the bug.

Key difference between working and failing workflows

intermediaire (works) sub/sub (fails)
inputSource workflowInputs (typed schema) passthrough
Parent’s Execute Workflow mapping defineBelow with typed values defineBelow with typed values

The parent’s Execute Workflow node uses mappingMode: "defineBelow" with a schema: [...] declaring 7 typed inputs (codeNorme, codeElement, recordId, paramValues, pdfUrl, categorie, data).

My current hypothesis : when the parent sends data via the defineBelow typed schema, the sub-workflow trigger must also be in inputSource: workflowInputs mode with a matching schema. Setting it to passthrough causes the items to be silently dropped at trigger time.

I have just patched sub/sub’s trigger via API with inputSource: "workflowInputs" and a matching schema. Testing.

Questions

  1. Is this hypothesis correct ? Is passthrough incompatible with a parent that sends via defineBelow typed mapping ? The docs are unclear.
  2. Why does the API GET show one set of params for the trigger but the execution snapshot embeds different ones ? Is there a server-side cache or normalization layer ?
  3. Is there a way to make a sub-workflow trigger accept ANY upstream input regardless of how the parent maps it (true wildcard) ?
  4. Is there a recommended pattern to avoid this kind of trigger/caller schema desync in long chains of sub-workflows ?

Environment

  • n8n version : 2.20.7-exp.0 (Self Hosted) (the bug occured only after I came back to a previous version of my Hostinger because i accidently deleted n8n and my workflows, I don’t know if that’s related)
  • Trigger node : n8n-nodes-base.executeWorkflowTrigger, typeVersion 1.1
  • Caller node : n8n-nodes-base.executeWorkflow with waitForSubWorkflow: false
  • Binary data mode : filesystem

Any pointer welcome — I’ve burned several hours on this.

@Armand_Ferveur
Exit the experimental version and use version 2.21.5 (stable)

I still have the same issue :smiling_face_with_tear:

" (Self Hosted) (the bug only occurred after I reverted to an earlier version of my Hostinger because I accidentally deleted n8n and my workflows, I don’t know if that’s related)"

@Armand_Ferveur, look at this point more carefully, restart and redo the workflow again on the latest version. I recommend not using exp v. in the future.

Yes, thank you. The problem was coming from the “Execute Sub-Workflow” node. I deleted it and recreated it and it works again.

:tada: :partying_face:
Very happy to hear that, count on us!