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