Recursive calling using webhooks

Questions
1

As part of a bigger project i want to dive into the possibilities of recursive calling of workflows. I started with this test. The workflow is published. In the node Call_Again I am using the production URL. WHen I check Executions I see 5 instances of the workflow running. But i would have expected that after 9 runs, as checked in the if statement, the workflow would stop calling itself. Somehow, it does not run as I expected. Where is my misunderstanding of how things work in N8N? Thnks

Describe the problem/error/question

What is the error message (if any)?

Please share your workflow

Share the output returned by the last node

Information on your n8n setup

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

Better to use recursive calling with the Execute Workflow node, because with a webhook, you may get unpredictable results (e.g., the ALB starts to think you are DDoS-ing the service, or the service may run out of free sockets (if there are a lot of webhook calls), and other issues)

3

Hello @Jitse_Schaafsma ,

It’s not a bug in your logic—it’s just how n8n manages traffic.

You have a chain of workflows waiting on each other. Execution #1 calls #2 and waits. Execution #2 calls #3 and waits. By the time you get to #5, all your available “concurrency slots” are full of waiting workflows, so #6 can’t start.

To fix this : Change the pattern from a Chain to a Relay Race .

  1. Add a “Respond to Webhook” node immediately after your Up_Var node (before the If node).
  2. Configure it to respond with “OK”.

Now, as soon as Execution #2 starts, it tells Execution #1 “I got this,” allowing #1 to finish successfully and free up its slot. You’ll never use more than 2 slots at a time!

2 Likes
4

Hello @Jitse_Schaafsma

From what I understand about your needs, I recommend running an internal loop without having to execute an HTTP Request, to avoid blocking your worker queue / webhook parity.

Create a workflow that includes a loop limiter based on $runIndex, and check whether that helps you.

If it does, please rate my answer.

1 Like
5

@Jitse_Schaafsma When you call a workflow via webhook from within itself, each call creates a separate, independent execution. These executions run in parallel, not sequentially. So what’s happening is:

  1. Execution 1 starts with var=1, checks if < 10 (true), calls webhook with var=2

  2. Execution 2 starts with var=2, checks if < 10 (true), calls webhook with var=3

  3. Execution 3 starts with var=3, checks if < 10 (true), calls webhook with var=4

  4. …and so on

But here’s the key, all these executions are running simultaneously. They don’t wait for each other. So you end up with multiple parallel executions, and the recursion doesn’t stop cleanly at 10 because the HTTP Request node doesn’t wait for the called workflow to complete before the current execution finishes.

Why You See 5 Executions:

You’re likely hitting n8n’s concurrent execution limit or the executions are completing before you check. The workflow is actually being called more times, but they may be queued or completing quickly.

Solutions for Proper Recursive Workflow Calls:

Use Execute Workflow Node (Recommended)

Replace your HTTP Request node with the Execute Workflow node, which properly waits for the called workflow to complete:

{
  "parameters": {
    "workflowId": "={{ $workflow.id }}",
    "fieldsUi": {
      "values": [
        {
          "name": "var",
          "value": "={{ $('Up_Var').item.json.Var + 1 }}"
        }
      ]
    }
  },
  "type": "n8n-nodes-base.executeWorkflow",
  "name": "Call_Again"
}

However, you’ll need to change your trigger from Webhook to Manual Trigger or Execute Workflow Trigger for this to work properly.

Hope this helps!

1 Like