Split Out-Execute sub-workflow-Monitor problem

[Florent14]

Describe the problem/error/question

I have a problem understanding how the “Execute sub-workflow” node works.

Context #1

Here is a “Test workflow v1” I use to test out the way this node works:

The “Start” node inputs the following data which reflects the structure of real data I am using elsewhere:

[
  {
    "schedulerResult": {
      "executions": [
        {
          "executionIndex": 1,
          "totalExecutions": 3,
          "delaySeconds": 30
        },
        {
          "executionIndex": 2,
          "totalExecutions": 3,
          "delaySeconds": 90
        },
        {
          "executionIndex": 3,
          "totalExecutions": 3,
          "delaySeconds": 150
        }
      ]
    }
  }
]

The “Execute Workflow” node call is configured as such:

… and calls this workflow (let’s call it “Subworkflow”) that waits the pre-defined number of seconds in “Start” node and sends back an email:

“Simple Init” merely initialises a local date:

const inputData = $input.first().json;

const nowUTC = new Date();
const LOCAL_TIMEZONE = $env.GENERIC_TIMEZONE || 'Europe/Paris';
// Local formatted time for display
const localDateTimeFormatted = nowUTC.toLocaleString('sv-SE', { 
  timeZone: LOCAL_TIMEZONE,
  year: 'numeric',
  month: '2-digit',
  day: '2-digit',
  hour: '2-digit',
  minute: '2-digit',
  second: '2-digit'
});

return [{
  json: {
    ...inputData,
    subProcessData:{
      localDateTimeFormatted
    }
  }
}];

Expectation

When I execute the “Test workflow v1” at “T” time, I expect to receive 6 emails at different intervals :

• 2 emails at T+30secs: one from “Test workflow v1” and one from “Subworkflow”
• 2 emails at T+90secs from the same
• 2 emails at T+150secs from the same

What happens

I indeed receive 6 emails but not at the expected times:

• 1 email at T+30secs from “Subworkflow” execution #1
• 4 emails at T+90secs from “Subworkflow” execution #2 and all 3 emails from "Test workflow v1" at once
• 1 email at T+150secs from “Subworkflow” execution #3

The execution of the “Subworkflow” happen at the correct times:

But not the result from “Test workflow v1”.

What is happening?!!

Context #2

For good measure, I tried a “Test workflow v2” version with a “Loop Over Items” to monitor the results:

Expectation

With the “Loop Over Items”, I expect this time to receive 7 emails:

• 2 emails at T+30secs: one from “Test workflow v2” —a “Loop email”— and one from “Subworkflow”
• 2 emails at T+90secs from the same
• 2 emails at T+150secs from the same
• 1 email at T+150secs from “Test workflow v2” —the “Final email”

What happens

I indeed receive 7 emails but again not in the correct order:

• 1 email at T+30secs from “Subworkflow” execution #1
• 5 emails at T+90secs: 1 email from “Subworkflow” execution #2 and all 3 emails from "Test workflow v2" at once —all 3 “Loop emails” AND 1 email from “Test workflow v2” —the “Final email”!
• 1 email at T+150secs from “Subworkflow” execution #3!!

The execution of “Test workflow v2” happens in 2 steps:

1. First, 3 items are passed onto “Execute Workflow” node

2. Then, once the 2nd “Subworkflow” execution happens, all items are passed to the “Loop Over Items” and everything happens at once

So, what am I doing wrong here?! Or is it possible at all that the output of “Execute Workflow” is a little problematic?

Information on your n8n setup

• n8n version: 1.113.3
• Database (default: SQLite): none
• n8n EXECUTIONS_PROCESS setting (default: own, main): default
• Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
• Operating system: Alpine Linux

[barn4k]

hello @Florent14

Seems the n8n doesn’t check if there is another execution in the wait state and returns all data after the first offloaded execution.

The wait node has one effect; it will process the execution right away, if the wait time is less than 65 seconds, and offload the execution to the database otherwise. As you have two executions being offloaded (the one with 90 secs and the one with 150 secs), n8n is considering ending the main process from the first offloaded execution.

You can check that the execution of the main WF ended at the same time as when the second sub execution ended.

[Florent14]

Thank you so much for your reply

So essentially, you are saying that the “Execute sub-workflow” node instances will not be executed completely independently from one another, but stay “linked” somehow.

I was expecting the node to “split” into multiple threads, one per item, and that each thread would then be processed independantly, one after the other.

In my real use case, I eventually used a Loop Over Items node before the Execute sub-process, using relative delays (to the previous execution) instead of fixed ones, so that each execution and following nodes happen at the planned, scheduled, times.

The Aggregate node ensures final steps are executed only once.

[Florent14]

If your question has not been solved, please let us know in a new reply on your original topic and we’ll get back on it.

I was asked by the forum system to provide a “best solution” reply. But even though barn4k’s answer is a very good explanation of what is happening, it seems to me that running multiple “Execute sub-workfolw” threads for multiple items does not work properly — unless within a “Loop Over Items”. But maybe that’s the intended result?