Split In Batches Nested Loops - New vs. Old Nodes

Describe the problem/error/question

Hello guys,

I’m trying to understand the behavior of the new Split In Batches node with nested loops. In my example workflow I’m using the n8n training node to get 2 items, split them into batches of 1 (outer loop), then get 5 more items and again split them into batches of 1 (inner loop).

The bottom route uses the old nodes and runs as expected. No Operation node runs 5 times for the first item and 5 times for the second item of the Customer Datastore (n8n training) 1 node.

The upper branch uses the new nodes and runs 5 times for the first item of the Customer Datastore (n8n training) 2. I can’t really explain what’s happening next. Note that I can’t reset the inner Split In Batches 1_2 node the same way as the old nodes - the workflow then runs infinitely.

What is the error message (if any)?

No error.

Please share your workflow

Share the output returned by the last node

Not relevant.

Information on your n8n setup

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

Hi @antitalent, this seems like an intentional change to me. Nested loops are often really hard to read, so the built-in “merging” of the new node version hopefully means you no longer nested loops and can simply build sequential workflows instead.

You can still keep using the old node version though if you prefer, simply copy it from your previous workflows to your new workflows.


Thank you @MutedJam, I understand it now. Wasn’t aware of the merge functionality, I thought the “done” branch is simplified “no items left”.

Often I need to update records after the outer loop is finished so in that case I need to use old nodes as it probably isn’t possible with the new ones.

Hi @MutedJam , in continuation of the original post, i also have a use-case which is way too frequent for me that i could use some feedback on.


What’s the recommended method of implementing this scenario with the new Split in Batches nodes, and not the old one?

A few more examples:

Have 150+ wfs, in a single instance, using the Split in Batches node and around 1/3 of them using nested loops.

Note: In almost all of these wfs, i don’t need the ‘merged’ output. I just need to process each output item / nested output item of the Split in Batches node in its own separate loop (not always in a sub-workflow), equivalent to a for loop (the original purpose of this node i suppose).

Hi @MutedJam.

Hi @shrey-42, looking at your example it seems you could just handle the inner loop inside your sub-workflow.

If this doesn’t work for you, just stick with the old node instead. If you’d like an alternative way of handling loops in the new node, you may want to write a separate feature request.

Hey @MutedJam , thanks for getting back on this.

Sure, sub-workflow is an option, but it’s not always the best alternative (particularly in view of the current UX).

This is a bit disconcerting for me.

Could you please share more as to why one of the core functionalities has been discarded/broken without any suitable alternative?
Because, from my experience and for programming in general, nested loops/foreach are indeed a fundamental entity, regardless of the Development tool being ‘visual-based’/‘low-code’/‘no-code’ etc.

Also, maintaining a repository of ‘old nodes’ doesn’t seem to be a very sustainable choice either. As there’s no official support/maintenance for them beyond a particular release, as well as it’s not really very convenient to maintain a private collection of old nodes.

Sure, will raise a feature request for this.
Although, i’m afraid it will suffer the same fate as another core node, the Function node (Recommendation: allow full-screen(-ish) editor for the Code node).


Hi @shrey-42, I am not involved in why such changes are being made I am afraid but perhaps @sirdavidoff can share some background around this.

@shrey-42 could you please give us a little more info on exactly what is going wrong?

Hey @sirdavidoff , basically, i’m trying to identify a way to implement my existing workflows as well as existing approach of developing workflows, with nested loops (examples given here:
Split In Batches Nested Loops - New vs. Old Nodes - #4 by shrey-42,
Split In Batches Nested Loops - New vs. Old Nodes
) with the new Split in Batches node.

Sorry, probably misunderstanding something. But from my understanding would you remove the IF-Node (which you used in the past to know when then loop is done), use the “done” output of the Split In Batches node instead and if you do not need the combined data which that node outputs by default, simply ignore it.

If that is not helpful please tell me what the problem with the above approach is so that I can provide a different answer or we can change the node to make that possible. Thanks!

Hi @jan, to explain some of my confusion with the new node’s operation:

  1. In the above example, the Set node (or any number of nodes in its place), should get executed a total of 10 times. But this happens only in the 2nd loop (old node) and not the 1st loop (new node).

  2. Also, i’m not clear as to why the new Split in Batches nodes show weird ‘execution count’, 3 & 7:



Note: i did not use the Reset option in the Split in Batches 3 nodes, as i perceive that that is now handled internally in the new node.

Also, if i do set the value of Reset to {{ $node["Split In Batches 3"].context["noItemsLeft"] }}, it results in an infinite loop:

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

Additionally to this, new node is using data from last node instead only from oryginally set data.

Split batch gets 4 items, sending only 2 (i set batch size for 1), and letting out 6 items in total in done branch.

I saw additionally that batch node is using data from last node in loop (in my case “true” from IF2 node).

1 Like

Hi @n8n_Team , could anyone kindly provide an update regarding this issue?


Perhaps @Jon could provide an update tomorrow when he’s back in, as it’s a bank holiday in most of Europe today? :+1:

Hey @shrey-42,

I still have a note to look into this in more detail I just need to find a bit of time. Looking at your workflow in the old version you would use the reset option which doesn’t seem to be working in the same way in the new version so it sounds like that is a bug that needs to be resolved.

Thanks a lot for making us aware of the issue. Had a look and found the “issue”. Have a PR ready locally and will after a conversation internally open it on GitHub.