When awaiting a sub-workflow, if that sub-workflow executes another workflow, the grandfather workflow starts running again after the grandchild workflow returns when I don’t believe it should. The middle workflow loops round to a wait and for some reason another copy of the middle workflow is spawned too. It only does this with a wait time of ~2 minutes in the middle workflow, if you only wait 1 minute the status of the workflows in executions remains Running rather than Waiting and the behaviour is as expected rather than this strange behaviour.
Please share your workflow
There are three to demonstrate the problem. I clipped then out of a bigger project trying to isolate the bug so they contain a bit of superfluous code.
This is the grandfather workflow. It calls the middle workflow. You can edit “Edit Here” node to fiddle with the time:
This is the middle workflow, called by the grandfather workflow.
This is the grandchild workflow. It is called by the middle workflow:
I don’t have time to look any further into it right now but i’ll forward this to the n8n team so that they can take a look. I did manage to reproduce the issue.
I did a very small amount of testing and the issue is not with nested execute workflow nodes 3 levels deep. I tested simpler versions of your workflow and it worked as expected.
But something about yours is causing it to loop. its running dozens of times every second when it should be waiting. But maybe i’m missing something too, i’ll take a closer look later if im able to
Thank you. It’s a bit of a show-stopper for me. I need to make sure only one copy of a workflow runs at a time (in an infinity loop, with waiting) so I made a simple (but a little more complex that others I’ve seen here) semaphore system and this bug stops it working. None of the other solutions I’ve seen on here fit my use case, there was one that queried an undocumented REST API (by the chap who owns n8n I believe) that was promising but that REST API seems to have gone now. I am trying to use heart beats to say “I’m still alive” so it will timeout after 30.5 minutes and a new copy will launch, having the infinity loop workflow renew it’s lock every 30 minutes to prevent timeout. I also wanted to use it with another workflow, where it would delete it’s lock, so when it went to renew the lock the workflow was automatically stopped in favour of the new workflow.
I saw a solution that did some of this (I think you wrote it actually) using both files and a Google Sheet before deciding to roll my own.
I might be able to work around it by only waiting a minute at a time (untested, but the behaviour of this suggests it might work) yet that’s not really ideal, I’ll only do it if we don’t receive any updates to this (potential) bug. Thanks for reporting it for me.
I just discovered something that may help with my use case and mean this bug no longer stops me. For anyone else who is trying to run only one workflow at a time, this could help:
I should have tried it first, this API, while documented, seems to no longer exist. I’ll go look at the API playground and see if I can find it. I’ll report back if I do.
Unfortunately, the returned executions from GetMany do not include the current execution if I add a wait to the end of it. It looks a bit flakey but might still suffice for my use case.
I made a Redis semaphore system using the API. It works quite nicely, I added the option to kill executing workflows but it errored when I tried it because you can’t call the execution delete api on running workflows apparently. I also changed my infinity loop workflow to trigger on a schedule and wait (using the Redis semaphore system). I don’t need this complicated flow anymore.