Share your feedback - help us enhance the loop over items node!

Could you please remove the "Replace Me" node? I find it quite frustrating.

Having to delete two items each time a loop node is added (the node itself and the looping arrow/edge) is very inconvenient.

One of the features I incorporated into my community node is the ability to execute the contents of the loop within a subworkflow. Additionally, there's a configurable option for a reduced number of items for manual execution, which then proceeds to the "done" branch after this subset has been processed.

• Add an option to include an $json.iteration (0, 1, 2, 3, …) with the item.
• Include an option for __start__ (if this is applicable within the Loop node)

I've often seen that nested loops can cause problems. Perhaps we could look into that as well?

Perhaps pinning data (1 batch) for testing. The difficulty would be aligning the batch size, which might change during the development and testing phase. Ignoring the batch size setting would be acceptable for me.

Yes, you'll need to utilize the $prevNode. If you modify the $prevNode and forget to adjust it accordingly, you might find yourself wondering why it's not functioning correctly. Making the reset process simpler would be beneficial!

2025-03-25_16-44-09512×378 26.4 KB

I've encountered a loss of reference when I'm more than 8 nodes deep within a loop. I'm unable to access the {{ $('Loop Over').item.json.url}} item because it doesn't recognize the current item.

I've also encountered a loss of reference in lengthy workflows that include a loop.

I'm unsure how to reproduce this issue, but it has occurred several times.

This likely relates to a specific node being used, such as a code or HTTP request node.

Using .item inherently carries risks. If it can't locate the corresponding item because it's missing or has been deleted, it won't function correctly.

Personally, I avoid using .item altogether and stick to all(), first(), and last(), as these methods provide certainty about the data you're retrieving.

For retrieving related items, a merge operation is recommended.

It would be great to have the ability to pin output data. This way, users wouldn't have to go through endless loops just to test their workflow every time.

I’m so pleased you are addressing this.

1. Nested Loops

Nested loops are sending data to the done branch instead of the loop branch. The workflow below demonstrates this issue. In this simplified setup, both Loop nodes are set to a batch size of 1.

I have been employing workarounds using sub-workflows and Code nodes.

image2084×914 87.6 KB

2. Loop Run Index

Could you make the currentRunIndex more accessible? I’ve been using {{ $('Loop over batch').context.currentRunIndex }} to track iterations and manage batches. This is an undocumented feature but proves very helpful.

Thanks,
Andrew

Yeah, I’ve discovered several workarounds for this problem.

But I hadn't encountered anyone who doesn't use .item.

That's quite fascinating. I'm not sure how this would function, but I'll do some testing.

I began using callin.io before the paired items feature was available, and when it was introduced, it wasn't yet reliable.

Furthermore, I prefer not to use workarounds, as they invariably become more challenging to maintain properly.

I recall searching for it and finding it in the documentation, but the UI doesn't offer any suggestions for the context within the loop node.

Additionally, incorporating a maximum number of iterations and a break condition would be beneficial.

Edit: I believe you can achieve both using a straightforward JavaScript expression within an If node now, but most users likely wouldn't be able to figure that out.

Thanks a lot for all the feedback received so far, everyone! Many of these points are already on our radar, but it's valuable to hear them reiterated alongside some fresh concepts.