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 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:
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
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
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:
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?
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.
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.
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.