Prevent Simultaneous Workflow Executions

[samaritan]

Hi,

I’m trying to build a reliable logic for preventing simultaneous workflow executions to avoid duplicated run. However, when I implement the possible solutions which are mentioned in community for that, I had some troubles.

1. Using /rest/executions-current Endpoint:

It is a good workaround to prevent simultaneous executions. However, there is a two bottleneck on this solution.

• Putting too much stres on n8n main. It causes “socket hang up” error. @krynble conveyed his thoughts on this matter well.

• Not working as expected if workflow execution duration is so fast and trigger interval is frequent @Denis_VICTORIA as mentioned on a related topic.

2. Using Redis or Similar Layers
   This is also good workaround for this case. Just get and set status of workflow as ‘running’ or ‘idle’ to identify whether workflow is running already or not. This working as expected in my case but unfortunately, this is not simple as it seems. Because,

• If the output of a node is empty, execution will stop without setting ‘idle’ of key in Redis. To overcome this, we must enable ‘Always Output Data’ option in almost every node. Then add ‘IF’ node that checks the output is empty or not, then connect it with both current flow and Redis set node.

• If we have error workflow on a workflow, error workflow also must be configured to set status of key as ‘idle’.

Here is a sample that I trying to build:

As a result, these solutions becoming challenging. I’m thinking that it would be great if we have option on each workflow to prevent simultaneous executions.

Please type your thoughts or vote the below polling to help n8n team for prioritizing this or not.

• I prefer trying to push limits
• I prefer this to be built-in

[yavetal]

Yeah, the second option sounds good - although you have some extra hussle.

[krynble]

Hey @samaritan thanks for creating this feature request, I think it makes total sense.

For the issues you mentioned, having to use Always output data is really not great but you’ve found a workaround, but for errors, there is also a possibility. You can use the Error Trigger node to handle whenever a workflow fails and also change Redis.

You can add the Error Trigger node to the same workflow you’re using and connect it to a Redis node that clears the flag.

[samaritan]

Hi,

I meant it actually, for that reason I’ve used Workflow ID for key in Redis. Here is the sample.

By the way, do you have any suggestion for ending workflows with Redis set node without using Always Output Data when nodes that don’t have output data?

[krynble]

@samaritan unfortunately I don’t see a reason without using the Always output data flag.