I have a workflow, that is scheduled to work for every 5 minutes. The workflow itself can be running from 1 sec (when there are no alerts from the 3rd party service) to 20 minutes (not that long actually, just to pinpoint the issue).
So, if the flow will be running for less than 5 minutes - everything is ok.
But if it is running for more than 5 minutes, n8n will start another execution while the previous one is still working and thus we are getting mess in the automation (duplications of data and some other artifacts)
Before the v1 I used a special flow that have triggered in my desired flows where I don’t want to get such kind of issues. That special flow is:
And I used it in my other flows just like that:
So generally it works like that:
my workflow that is running for every 5 minutes, have a check if there are another running executions and if so, the flow will stops. Otherwise it will be proceeded.
in v1 seems there are no more ‘/rest/executions-current’ API endpoint. The n8n API node is also doesn’t help as it doesn’t display running executions. And the question is: how to tell n8n to not execute workflow if it is already running (like run once option, but for workflow itself, something like ‘run single only’)?
Information on your n8n setup
n8n version: 1.4.0
Running n8n via (Docker, npm, n8n cloud, desktop app): docker
Hi @barn4k, this was always an undocumented API and it’s expected to change without notice.
That said, n8n still sends requests to the /rest/executions-current endpoint for me, even in v1. So you should still be able to hack your way around this.
A cleaner solution would be the use of a queue though as suggested by @BramKnover here? So perhaps you want to send the relevant data every 5 minutes to a queue in your main workflow, then have a separate workflow consuming the queue?
Hi @MutedJam, Yes, that probably would be an option. Another way, in my opinion, is to use a flag in global variables (like const lock = true in the beginning of the flow and const lock = false in the end). But what with the /executions endpoint? Why it doesn’t return the running executions?
That is an excellent question, unfortunately I do not know the answer to this. Perhaps @sirdavidoff from our product team can share some background on the reasoning here?
It is bad practice to use undocumented features as @MutedJam mentioned they can simply break without notice.
Also if you have flows running this often and they are able to take a while it is a good idea to add a queue to it to make sure the server doesn’t get overloaded. Same for incoming Webhooks that do not need a direct response. If you cannot control the time a workflow is running and/or how many will be running at the same time always try to offload it to a queue so you can stay in control.
Can you share an example workflow please with demo data to see the flow of this proccess? How to start the worflow, what to send to RabbitMQ, what to wait etc?
