I can confirm that the sub-workflow is getting treated as complete even with a JS code node after a Wait node. Any ideas on how to deal with it? Should it be considered a bug? To me personally, I expect it to wait for any kind of node to complete to conside a sub-workflow to be complete, that’s the way it should be in my opinion.
I do like the idea of the main workflow to loop infinitely BUT in that case I’m getting some kind of memory issue after some time. This is pretty much why I opted for this sub-workflow workaround, maybe the memory issue can be fixed somehow as well? Then I would just use the infinite loop in my main workflow. Any help would be highly appreciated.
I will definitely try the Merge node workaround, thank you. Can’t see anything related to this issue in the 2.15 release notes, it’s only MCP-related but will update anyway to see if it changes anything…
For the cleanup, do you mean theEXECUTIONS_DATA_MAX_AGEenv variable? But I don’t actually understand, I mean why the memory doesn’t get overwhelmed by every-minute executions but for some reason does by basically the same but in the loop, that feels like some kind of memory leak issue…
Yeah I get what you’re seeing. That behavior is pretty in line with how n8n handles Wait nodes. Once it reaches the Wait, the execution is effectively persisted and detached, so the parent workflow can treat the sub workflow as finished even if there are still nodes after it.
So it feels wrong from a workflow logic perspective, but it is more of an execution model limitation than a clear bug.
The memory issue with the infinite loop also makes sense. Long running executions on self hosted n8n can start piling up over time, especially if the workflow keeps carrying data through each cycle.
What usually works better is keeping anything with a Wait in the main flow, or breaking the loop into smaller fresh executions instead of one long running one.
You’re definitely not thinking about it wrong though. It is one of those n8n behaviors that only starts showing up once the workflows get more advanced.
That’s a very bad practice. Instead of running the execution endlessly, use a relatively small schedule (1-2 minutes each) + state entry in the Data Table.
The logic would be:
main WF - check if the data table entry state is waiting. If not, proceed to the sub workflow. Set the Execute WF option “Wait For Sub-Workflow Completion” to false. Set the state in the data table to waiting.
In the sub workflow, set the completed state in the data table once the flow finishes.
In the main WF, check if the state is completed. Then do the logic related to the completed state. Make sure to set the state to anything else (e.g. processing), so the next run won’t be executed with the same completed state, while the first one is still working.
The data table may be like
state
last_exec_id
unique_id
waiting/completed/processing
$executon.id
my_loop
And you can get the row by filtering on the unique_id field with the ‘my_loop’ value
PS, by checking the updatedAt field of the data table you can set a fallback behavior to clear the state if isn’t changed for the desired time (e.g. the sub-wf timed out or has an error)
Isn’t all this exactly how the ‘Wait For Sub-Workflow Completion’ option supposed to work? What’s the point of the option if I have to create all this myself?
Too be honest I never run into this as in my opinion it is bad design having flows wait for a longer period of time. Better to offload to a “processing table” and then take it from there when it should continue.
but this option is supposed to work exactly like that, just without the need to reinvent the wheel aka create all this structure manually… well at least in my opinion I wonder if it should be reported to devs or maybe I’m just not getting something here and this option actually works as intended?
I have the same problem. I have four different routes in my main workflow, but the routes are processed one by one, starting from the first. It’s a waste of time that there’s no parallelism when “Wait For Sub-Workflow Completion” is disabled, because when I turn that option off, the data passes through without being processed.
Whether you are waiting for a sub WF to complete or not. If not - you will need to store all sub WF states somewhere and check periodically in the main WF whether all subs are completed and we may proceed or wait more.
and updating to the latest version also didn’t fix anything…
