Describe the problem/error/question
Hi,
I encountered a strange problem where Loop Over Items node executed more times then input item count. It is a fairly complex set of workflows so it will be difficult to share them here; however, I have taken a few screenshots from 2 different executions when this occurred. The workflows run as follows:
Main Loop (with Wait on Webhook Call) via manual trigger → Init Step via webhook trigger → Process Steps via webhook triggers, when all steps are completed, call the Main Loop’s $execution.resumeUrl.
Screenshots of the Main Loop are shown below and I have checked the workflow executions for the Init Step workflow to confirm duplicate executions were created a few ms apart, ie it’s as if the Main Loop fired duplicate HTTP Requests consecutively.
1st occurrence:
2nd occurrence:
I used the public REST API to retrieve the execution info of the last duplicate Init Step workflow executions:
{
"id": "4395",
"finished": true,
"mode": "webhook",
"retryOf": null,
"retrySuccessId": null,
"status": "success",
"createdAt": "2025-08-21T18:17:20.333Z",
"startedAt": "2025-08-21T18:17:21.388Z",
"stoppedAt": "2025-08-21T18:17:37.134Z",
"deletedAt": null,
"workflowId": "ch4vhCN64QQfhQex",
"waitTill": null
}
{
"id": "4396",
"finished": true,
"mode": "webhook",
"retryOf": null,
"retrySuccessId": null,
"status": "success",
"createdAt": "2025-08-21T18:17:20.349Z",
"startedAt": "2025-08-21T18:17:21.664Z",
"stoppedAt": "2025-08-21T18:17:35.617Z",
"deletedAt": null,
"workflowId": "ch4vhCN64QQfhQex",
"waitTill": null
}
What is the error message (if any)?
Please share your workflow
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
Share the output returned by the last node
Information on your n8n setup
- n8n version: 1.105.3
- Database (default: SQLite):
- n8n EXECUTIONS_PROCESS setting (default: own, main):
- Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
- Operating system:
Additional note, the execution history of the Main Loop, retrieved via public REST API, does not show count discrepancies as shown on the original screenshot. In other words, after I refresh the screen and pull up the execution history, it no longer shows any discrepancies between the input item count and execution counts within the loop. However, evidence of duplicate webhook calls, ie Init Step that are a few ms apart remains intact.
Update.
I believe I have found the root cause. In my setup, the 3rd workflow, Process Steps uses a loop to process varying number of steps depending on the input, at the end of the loop, it sends Http Request to the Main Loop’s $execution.resumeUrl. Because I did not use an aggregate node, 1..* Http Requests were sent.
Meanwhile, the $execution.resumeUrl appears to be the same for the entire execution/session, ie the $execution.resumeUrl is the same for all items in the loop. It seems that when the wait node received multiple web hook messages concurrently, it behaves in a nondeterministic way, ie sometimes it advances the loop index, other times it repeats the loop without advancing the loop index causing duplicate executions.
Furthermore, the execution details on the Main Loop drops/omits these misfiring unless the user happens to be running the workflow interactively and “catches it in the act” so to speak. Because I kept my last interactive execution window open and I was passing along the loop item’s PK/ID as query parameter when calling the $execution.resumeUrl, I was able to see that the Main Loop's wait node webhook received duplicate messages for some PK/IDs.
In case if anyone encounters similar issue, I have mad the following changes to my workflow to solve this issue:
- Add aggregate node after
Loop Over Items “done” port so the $execution.resumeUrlwill only be called once. This should’ve been done in the first place.
- Added a check after the
Main Loop's wait on webhook call node to advance the loop index if an only if the PK/ID match otherwise it goes back to wait state.
I would like to request that as a future enhancement to make $execution.resumeUrl"assignable” or single use only. Furthermore, the workflow execution does not seem to persist ALL the details which makes debugging of this issue more difficult. In this case, when I pulled up the execution detail of the 1st occurrence, everything looks fine with no problem, different from the screenshot I kept. I believe it is imperative for a workflow engine that all execution details are faithfully preserved to better aid users in debugging any workflow execution issues in production.
