Unexpected result in a loop execution when both true and false output of IF node being traversed

Hi, I’ve a loop logics and expected each iteration to complete before the start of other loop however I’m seeing unexpected result.

First, when all result traverse the same path it seems working.

The IF node evaluate the http request result and the issue surfaced when the iterations uses true and false as output.

For this problem, it seems executing false (create object) but not completing the nodes, while on executing the true path it uses the details intended for the false path hence error.

I’m accessing the inline node output without first().json while any prior node variable before Item Lists node with first().json.

On another time, it seems neither path is completed, and it failed when the value meant for the true path is used on the false path.

I did not reconnect the last node of both true and false path back to the Item Lists node. Any idea why the Item Lists can be so unpredictable when going thru multiple path?

Look likes the execution resource couldn’t finish one path and jumping to another as if the observation below:

Information on your n8n setup

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

Hi @engowen!

This is hard to say without seeing your workflow - but seeing you mention " it failed when the value meant for the true path is used on the false path" might mean that an expression you’re using isn’t quite what doing what you’re expecting it to.

Could you share if you’re using any expressions in your if nodes, and provide a reproducible example so we could dig into this further with you?

hi @EmeraldHerald , since the execution of the workflow for iteration isn’t as expected, the only way is to put the $itemIndex for the node value i’m accessing.

However not coming from JS background i’m struggling to use the correct syntax.ie. Any idea how do I use $itemIndex in the item collection to get Bearer 12345 of id:2 ? I’m lost without intellisense :slight_smile:

None of this works.
{{ $node[“mock token1”][1].json.test }}
{{ $(‘mock token1’).item[$itemIndex].json.test }} ?

Thanks for the reply! Unfortunately though it’s still not giving me enough context here to really help you out - could you give a simplified and reproducible example workflow, perhaps even just a quick separate workflow with mock data in a “set” node? That way we can actually play around with what’s happening and figure out the issue, and would save you sharing JSON screenshots :sweat_smile:

Please use this workflow.

Apparently this is reproducible.

In my mock token1, the test variable is set to

the output for true path is correct:

but the output for the false path is not:

1 Like

Thanks so much for that!

Using the example workflow, $itemIndex always returns a number. Your if node is using a string comparison instead of a numeric comparison. If you switch this up to look for a number condition, this should work, like this:

If you run into another problem, feel free to share another example, but this should at least fix this part up for you!

Thanks for your reply, yes make sense using the number for comparison.

sorry I was tweaking my post couple of times, I believe I’m reproducing the issue as per my main WF. Can you see if it make sense for the highlighted inconsistency?

Please use this workflow.

In my mock token1, the test variable is set to

the output for true path is correct:

but the output for the false path is not as the expected value are 12341 and 12342. it should be the same as $json.test. In my development WF, I couldn’t access use $json.field as each HTTP Request node override the previous HTTP Request node output.

It seems each IF node path within Item Lists node assume the node reference index start from 0 instead of the current loop index. @EmeraldHerald Is this a bug?

While the loop within Item Lists shouldn’t output unexpectedly, I’d found a workaround by introducing SplitInBatches effectively confining the data to the current iteration with batch size 1.

Glad the result worked out to be expected. Still, the original problem shouldn’t surface and to invest in hours to identify a workaround. However i’m experiencing performance vs reliability choice for my production workflow as without SplitInBatch node definitely performs better when only 1 IF output is executes.

Hi @Jon , can you confirm my finding at post #5 is a bug or work as design? Thanks.

Hey @engowen,

It looks like it is a bit of both, If you just use $('node name').json.x it seems to assume the current run index for trying to get the item, What you would need to do instead is use $('node name').item.json.x which will instead try to use the paired item if found.

We don’t tend to document the older style of $().json anymore so it would be worth looking into the updated syntax which you can find here: Built in methods and variables reference - n8n Documentation

Hopefully this helps.

1 Like

Hi @Jon

Unfortunately when I introduce another parameter using $(‘node’).item.json.X the process failed.

The 2nd and 3rd iteration is calling the failed node but according to your syntax it should know the expected value is Bearer 12341 and Bearer 12342.

The failed workflow is

Hey @engowen,

For me it is working as I would expect.

With the output of the bottom set being…

Hi @Jon That’s the expected outcome! I’m still consistently getting the same error on 0.222.3. Which version are you on? I ran the update cli but no change to the version.

npm update -g n8n
image

Hey @engowen,

I am on the current latest release which is 0.225.1, It sounds like this is probably something resolved between 222 and 225.

2 Likes

I’d upgraded to 0.225.2 and the issue is now fixed. Thanks @Jon .

2 Likes

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