Loop Node Only Processing First Item - How to Resolve?

It appears your topic is missing some crucial details. Could you please provide the following information, if relevant?

• callin.io version:
• Database (default: SQLite):
• callin.io EXECUTIONS_PROCESS setting (default: own, main):
• Running callin.io via (Docker, npm, callin.io cloud, desktop app):
• Operating system:

Please provide the requested information.

Welcome to the community!

There's no advanced technique here. You are currently sending only one item to the Loop node at a time, which means only one item is processed per iteration.

The logic of your workflow doesn't seem quite right to me. The loop is typically used to break down a set of items, not when you only have a single item.

For instance, try this alternative to verify that the Loop node is functioning as expected:

image1356×592 51.4 KB

Hello,
Thank you for your support.

This is a generic flow I used to understand the node’s behavior.
Yes, I am sending one item at a time, and that’s the desired behavior. The point is that the Loop processes only the first item sent, while the following ones go directly to the output “done.”

Notice that I send 3 items to the Loop, but it only processes one.

In the real case, an AI model sends a “requires-action” that contains an array of calls. This array is sent to the Loop node and is processed. But meanwhile, in the same thread, the AI can send another “requires-action” item containing another array of calls… this second item goes straight to “done” without being processed.
And then, my next node after the LOOP picks up a data structure that hasn’t been properly processed.

In your example, it works perfectly. But I receive the items at different times, and I can’t combine them.

This is my real flow.

1863×187 36.5 KB

21209×748 65.6 KB

No, you are still misreading it. You feed 3 items to the Loop separately, not in one set.

See the difference.

Separate items - 3 sets of 1 item

Single set of 3 items

image322×638 13.7 KB

That's what I meant; your usage of the Loop didn't make sense to me. It cannot work the way you want by design. You need a different approach. Here’s a quick demo of what it might be to assemble items together.

Yes. That’s clear.

So the LOOP node doesn’t support multiple items separately?! Do you have any idea what approach I could take?

Look at the flow from a real case… I can receive multiple items coming from the Switch, at different times. The first item coming from the Switch goes through the LOOP and iterates fine. But the second one goes straight to the DONE output of the LOOP without being processed.

11262×464 120 KB

Here you can see that all 36 items within the first item sent to the LOOP are iterated. But the second item goes straight to DONE with its other 36 items.

21237×810 91.7 KB

That is accurate. It appears you're still having difficulty understanding how the data processed by the Loop is displayed in the UI. The final output is indeed the aggregation of all iterations exiting the “done” branch. To be more precise, each individual iteration is consolidated into a set. This means individual iterations proceed to the “loop” branch, and then all of them are combined and exit via the “done” branch. Consequently, the UI presents them collectively. The final output does not pass through the “loop”; it reflects what emerges from the “done” branch as the concluding stage of the Loop node's processing.

Thanks for your patience.

Your explanation is clear to me.

When I mentioned “second item,” I was referring to a second concrete array that goes to the LOOP node, not the second item that appears in the DONE output summing the iterated items from the first array.

Take a look at the example I posted in the image. Initially, I sent an array with 36 items to the loop. The system iterated through all the items, and in the “done” branch, 37 items appear (the 36 items from the array plus the summed item). So far, everything is fine.

However, when I send a second array, this time with 34 items, to the LOOP, these items are not iterated as they should be. Instead, they go directly to the “done” branch. As a result, the 37 items that previously appeared in the “done” branch, containing the 36 iterated items, increase to 38, but these 38 include the 34 items that were not iterated.

Hey, it seems you are correct. I can replicate this behavior with a simpler workflow for better clarity. It appears the second set of items isn't being iterated over; instead, it's being combined with the initial outcome of the first set of iterations.

I suspect this is a constraint of the Loop node. Currently, you cannot feed the "done" outcome back into the Loop's input, even indirectly through other nodes.

You might need to explore alternative solutions. For instance, you could use another Loop node for the second set, referencing $runIndex or implement the loop logic as a separate workflow.

Hello,

I've just looked into this. The Loop node can indeed be challenging at times. In this scenario, the reset option is necessary to signal to the Loop node that it's receiving a new set of data. However, as you likely observed during testing, simply enabling reset will cause it to run indefinitely, as it resets for every item coming from the loop branch.

This leads to the question: How can we reset it for the second run of items? The example workflow provided is below. In this workflow, we want the output of the Debug Helper in the loop to run twice. Without the reset, you'll encounter the issue you're seeing.

image1281×671 94.3 KB

To resolve this and reset the data correctly, we need to ensure that the data is only reset if the preceding node was the If node. This prevents us from continuing with the first item when the code node loops back. To achieve this, open the Loop node and add the reset option, but configure it to use an expression. For the expression's value, use {{ $prevNode.name === 'If' }}. This will return true if the previous node's name is 'If', thereby resetting the loop.

Executing the workflow now yields the following result:

image1270×684 94.9 KB

The loop node has executed 14 times (once for each item and once for each done branch), and the 12 items have been processed correctly.

Please let me know if this solution is helpful or if you have any further questions.

Thank you guys so much. That works perfectly.
I was about to go crazy with this situation for a couple of days

This discussion was automatically closed 7 days following the last response. New replies are no longer permitted.