In the context of a workflow including function / code nodes which are positioned after a Human-In-The-Loop node, the function / code nodes (containing JavaScript code) are silently failing ; Other nodes after the HITL are working as expected, until the workflow progress reaches a function / code node.
Once the HITL has been processed / validated, it seems that none of the function nodes in the workflow are working anymore ; Any function nodes which are positioned before the HITL node are working well. Considering this, we moved the function nodes which were positioned after, before the HITL. However, this fixed the issue only when the workflows processes single or multiple items in a single iteration, and for the first iteration of a Loop Over Items node when processing multiple items. During the 2nd iteration of the Loop Over Items, the workflow keeps the context âPost-HITLâ and therefore, none of the function nodes are working anymore and the workflows silently stops.
The silent fail of the Function nodes in the context previously described generates no error output / logs ; itâs required to stop the workflow manually, and then no error message triggers and the execution logs shows only a âCanceledâ Status of the execution : the UI only shows that the workflow went through the HITL node, even if the nodes (which arenât function nodes) placed after did work perfectly well.
The workflow which Iâm speaking about was working fine when my n8n instance was under the version 1.104.1. Since updating it to the version 1.2x and 2.3.4, the workflow doesnât work anymore due to the context of the HITL. When the HITL node is removed in the mentioned workflow, the entire workflows works perfectly well.
"
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: Current n8n version : 2.3.4 (Self-Hosted)
Kindly find a picture of 3 scenarios which are reproducing the different steps of our workflow and showing the global approach which fails following to a HITL node. Our current workflow is way bigger than the ones shown in our example, but we would like to avoid complexity in this issue assessment and ensure us confidentiality around the process we are applying in this workflow.
Hey @Eolyas As i can see the types of scenarios you have shared, i guess the problem is with the OUTLOOK node, have you tried repositioning the HITL node and after another node place the confirmation message node, this ensures no failures on Outlook end which might occur or slowly cause the workflow to fail. so what i mean is that your workflow might look like :
Thanks a lot for your suggestion! Unfortunately, this doesnât really help us⌠in our workflow, we have already several nodes between the HITL node and the Outlook Confirmation node, therefore we concluded that this might not be related to an Outlook overhead. In the example youâre suggesting, during the first iteration, youâll get the HITL email and be able to approve or decline the request. In both case your answer will lead to nothing and the workflow will never follow the process, the confirmation message will never be sent and youâll have to stop the execution manually to end up with no error message / log. The execution logs will show an execution stopping at the HITL node (like if no answer were received) and its status will simply be showing âCanceledâ with no visible error.
This is entirely due to the fact that a function node was positioned between the 2 Outlook nodes. If you remove the function nodes, the first iteration will succeed but it will again fail during the second iteration of the Loop Over Item, as soon as it reaches a function node.
After many tests, with different ways of node positioning, the single progress we made is to have at least one working iteration, by moving the function node before the HITL message; following to our tests, we have concluded that the issue is related to the function node type positioned after an Outlook Send and Wait message context. As soon as your function node are positioned before the Outlook HITL, it works for a single iteration. Not for multiple iteration when looping the process with a Loop Over Item node
Alright, Can i get a little more information about what actually the complete process looks like so i can try finding maybe another way to do so without compromising the entire process silently failing, as even i use HITL nodes for other services this is first time i am encountering that, thatâs nice we got to know that something like this may happen, sure let me know if you can share more of the flowâs information and process so maybe we can achieve a solution to this
What youâre experiencing is a known limitation in newer n8n versions when combining Human-in-the-Loop (Send and Wait) with Code / Function nodes, especially inside Loop Over Items.
After a HITL, the workflow execution is resumed asynchronously, and JavaScript-based nodes rely on execution context that isnât fully restored across iterations. Thatâs why it works before the HITL, works on the first loop iteration, and then silently stops on the next one â while non-code nodes continue to run.
Current best-practice workarounds are:
Move all Code / Function logic before the HITL node
Or split the flow into two workflows (pre-approval and post-approval)
Or replace Code nodes after HITL with native n8n nodes where possible
This matches the behavior change seen after upgrading from 1.104.x and isnât related to Outlook or node ordering.
Hopefully this helps clarify the root cause and avoid further debugging loops.
