OK - I guess I see it now. Because Input 1 is always there, it works.
Well, I guess that is one way to do it. You have to add an extra dummy IF every time tho.
Doesn’t that seem quite hacky?
Still, if it works, I guess it works.
If you were replicating this pseudo code where both paths generate different outcomes, would you need 2 extra IFs?
if (sheetExists) {
renameExistingSheet();
} else {
createNewSheetWithName();
}
I would really prefer to replace the Merge with a dedicated “FI” or “END IF” node that has 2 inputs - for the FALSE and TRUE branches. I looked at this briefly but could not see how to make it.
I added a feature request to add a dedicated “END IF” node that would merge the TRUE and FALSE branches directly. I’d gladly work on this, if someone can give me a pointer - maybe another node (Merge?) that I could use as a starting point.
Having a similar problem here. I created simulated data to follow the FALSE path. (below)
Data flows through FALSE path correctly but then it’s not recognized in the Merge node. Any solution for this? Is it a known issue, or am I doing something wrong?
It’s counterintuitive but there is a workaround as mmac described above. You add an IF prior to your IF, set to always true, always send output. Then you feed that and the outcome of the ‘real’ IF to Merge, and set it to enhance the output from the always-true IF. Apparently, then the merge will continue, even if the real IF returns nothing.
Another solution is to put your IF into a sub-workflow with 2 outcome branches. This is what I’m doing - it’s cumbersome but it works.
Just adding my two cents here, because I’m wrestling with the same problem and it’s REALLY frustrating to have to work out some kind of clever, situation dependent, hard to document workaround for this behavior.
I understand that it’s a documented “feature” that MERGE after IF will trigger back execution. I even understand why that has to be true when merge is used in the various “combine” modes.
But I don’t see why that has to be true when using MERGE in “append” mode. In that mode, MERGE should take everything from the true branch then everything from the false branch. If there’s no input on one of those branches it shouldn’t care. And it certainly shouldn’t force/trigger an execution on that branch. I’d bet that append mode is the most common use case for an “IF/MERGE” structure.
So where do I submit a feature request to change the behavior of MERGE in append mode?
Personally, I’ve resorted to avoiding the Merge node and instead build sequential workflows in such cases, where the merge then happens in a Code node. An example would be available here: [Merge node] merging multiple outputs - #4 by MutedJam
Lastly, I know Jan is working on a way to avoid this behavior in the pull request mentioned in this thread: Merge (wait) seems broken - #3 by jan. This is at an early stage though and not fully tested yet. So there is no definitive ETA yet I am afraid.
Thanks for the update @MutedJam!
Since posting this, I’ve resorted to ignoring the issues and testing in “production” mode. It appears to “fix” it and it seems you can have multiple branches coming into any branch just as long as you don’t try to test each node.
Thank you - just voted for the “disable triggering” feature request. I’ve tried avoiding the need for merges but there’s a lot of situations where it’s inescapable. Last night I was working on something where two different streams wound up with IF modules, giving me 4 possible situations that needed to be handled. Normally that’d be fine, but Merge’s tendency to fire the lines that weren’t supposed to fire made it really tricky.
More broadly, the point of graphical no-code or low-code systems is that you don’t have to spend a lot of brainpower on complex, elegant, or tricky solutions to problems. You should just be able to “wire it up” and have it work and move on to the next thing. The biggest problem with MERGE is that it’s so unintuitive.