I’m trying to regardless of the “IF” node result, to run the same nodes, and in the end use “merge-wait”
so only if the “IF#1” node was true, It will perform additional logic (aka AND logic gate),
This is done to avoid code duplication.
I could use different methods to achieve this, but in the end this way should work too.
After some testing, it seems that the "Merge"node activates when input1 arrives, even if 2nd didn’t arrive yet.
After Additional testing, seems like the “Merge” node is forcing “input2” closest node to be activated even if it shouldn’t, at least the “Wait” node.
Information on your n8n setup
n8n version: n8nio/n8n:0.179.0-debian
Database you’re using (default: SQLite): Default
Running n8n with the execution process [own(default), main]: Default
Running n8n via [Docker, npm, n8n.cloud, desktop app]: Docker
EDITs: formatting and clearer explanation
Hi @ToxicFi7h, this is the expected behaviour I am afraid. The Merge node will pull in data from each input, even if the connected nodes wouldn’t otherwise run.
Hi @MutedJam Thanks for the explanation, It wasn’t clear from the docs.
I’m still not sure with the “Merge-Wait” node that could be running without waiting for both inputs to arrive (But in the same time it does wait if the input that didn’t arrive is Input1), could you please help me understand the logic behind this?
because From what I’m seeing, the main input is input1 and input two isn’t mandatory for merge execution even on “wait” action;
thous if the logic is complex enough and it’s relying on Wait Logic, and there’s situation that input2 wouldn’t arrive, the “merge-wait” node still run if it the one that didn’t arrive is Input2 (compared to Input1 in the same situation).
From the doc:
The items passed into Input 1 of the Merge node will take precedence.
But that’s not clear to me that Wait wouldn’t wait for input2…
Thanks again for reading all of this.
You’re quite right, this is confusing and I have suggested we’ll add this to the docs or make the Merge node’s behaviour optional.
For your IF case you can simply skip the Merge node altogether though. There is no need to Merge your branches if only the true or false path are executed:
Your idea is great with the information I gave.
My solution (Still, not good as , merge-wait logic ) was to use additional “IF” node that is triggered with the main workflow, with reference to the initial IF result ( so I do not need to worry when using “keep only-set” on the flow).
To understand better, the following flow is why I opened this thread for help:
Hey @MutedJam , found this question, and have a similar one.
I have a complex workflow with if branches that executes other workflows, then I use merge nodes on the “append” setting to reunite the different branches.
The issue I have is that some items might go to each branch, but there are some branches that wont receive items at all.
What is happening now: The merge nodes are forcing execution on the “execute workflows” and giving me errors. If I use a NoOp node and items go through multiple branches, it wont merge them right?
I am not sure if it works for the wait function, but this work around worked for me:
UPDATE: this work around sometimes skips items, so I am back to the drawing board
Hi @jpm, is there a perhaps a chance you can arrange your workflow in a sequential manner? So that you wouldn’t need the merge node? Check out [Merge node] merging multiple outputs - #4 by MutedJam for an example.