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
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.
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 @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.
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.
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!
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).
Also, i’m not clear as to why the new Split in Batches nodes show weird ‘execution count’, 3 & 7:
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.
