Please remove the “Replace Me” node. I hate it with a passion.
Having to delete 2 things every time you add a loop node is very annoying. (delete the node and the looping arrow/edge)
One of the features I added in my community node is the option to execute whatever is inside this loop inside a subworkflow.
And also a configurable reduced number of items for a manual execution. ( that does then continue to the done branch after this subset was executed)
Maybe pinning data (1 batch) for testing purposes. The challenge would be to match the batch size that may get changed during the develop-and-test cycle. Disregarding the batch size setting would work for me.
I experienced loss of reference when I’m 8+ nodes down the line in a loop. I can’t call the {{ $('Loop Over').item.json.url}} item, it doesn’t know what the current item is.
Probably has to do with a certain node used. For example code or http request.
Using. .item is always with its risks and if it cannot find the paired item because it is lost/removed it will not work.
Personally I never use it only use all(), first() and last() as you always know exactly what u are getting.
If you need related items use a merge.
Nested loops send data to the done branch instead of the loop branch. The following workflow illustrates this issue. Both Loop nodes have a batch of 1 in this minimalist example.
I have been using workarounds with sub-workflows and Code nodes.
Could you make the currentRunIndex more accessible to others? I’ve been using {{ $('Loop over batch').context.currentRunIndex }} to keep tabs on the iterations and manage batches.
This is an undocumented feature but it’s very useful.
I started using n8n before we had the paired items. and when it was introduced it was not reliable yet.
Also after I don’t like using workarounds. As it will always be more difficult to maintain properly.
Thanks a ton for all the input so far everyone! Many of these points are already on our radar but it’s good to hear them echoed again alongside some new ideas as well
I have wished the UI would leave no option for failing to “close” the loop, and make it clearer that every item going into the loop should go through to the end somehow (since putting an If or a Filter in the middle of a loop seems to be just as troublesome as nesting another loop. Sometimes the solution to that is to pull the the steps in the loop entirely out into a callable sub-workflow, making it a single step, but then tracing through executions becomes more challenging.
From what I can tell, the main reason for using a loop-over-items is to avoid the “process everything right now, in one go” behavior you get from a node, with a list of items.
What if loop-over-items were changed to an in-workflow “batchable” sub-process.
I would like to have an option in the loop configuration so that instead of receiving all the results of the loop, I could only receive a completion status.
This would make the response cleaner as a trigger for another action.
first issue - the way the nodes reflect items counts is really wacky – consider nested loops - if a single item running thru the loop creates 4 sub items like a split and we loop over those 4 items – the counts somehow explodes into hugh numbers … its like a cartesian product … –
see the example – 15 items main loop - for each item in the main loop, i created 4 items and action them, then return to the main loop. where does the 480 come from.
second related issue - looks like the loop outputs are kept in the different runs - great but counting them and displaying that is not as useful - imho nobody loops over 1000s of items to collect them to then do something after , yes, they can but in practice, collection large number of items can in some cases cause OOM as well as complete loss of all the items if something fails … we batch cuz we can to do things step wise n commit and loop (just 1 way to handle item processing)
Just make the reset easier!
