Unexpected behavior from unvisited nodes in a Switch-and-Merge workflow

[ari]

I have a set of items that I want to process conditionally, and tried using a switch-and-merge pattern (using the Append mode) to do this. When the switch node outputs at least one item of each branch, the merge node behaves as expected. But when the Switch node outputs no items of some branch, the nodes in the unvisited branch still run.

Here is a minimal example:

Output returned by the last node

[
	{
		"Type": "A",
		"x": 1
	},
	{
		"Type": "A",
		"x": 1
	},
	{
		"Type": "A",
		"x": 1
	},
	{
		"shouldneverhappen": 1
	}
]

This feels like a bug, but perhaps I’m just misunderstanding something about how Merge is supposed to work.

n8n setup

• n8n version: 0.156.0
• Database you’re using (default: SQLite): postgresql
• Running n8n via [Docker, npm, n8n.cloud, desktop app]: Cloudron

[jan]

Welcome to the community @ari !

Yes, that is currently expected behavior. The Merge-Node needs always both inputs to execute to move forward and executes the second by itself, if it did not before. There was recently another discussion about it here:

removeKeyMatches Merge Node returns nothing if the comparison node is empty

This is something I also have a hard time with. It’s a consistent behavior of the Merge node. Both inputs must have data in order for the node to work at all. For me this requirement really limits my workflows as if any of the merge inputs is conditional I can’t be sure the workflow will work correctly and I am yet to find a convenient workaround. Also reading this old post from @jan it may not have always been like this:

Additionally also here a feature request regarding this behavior:

Merge node suggestion: add option to disable triggering of previous nodes

The idea is: The Merge node has a unique behavior in which it activates connected nodes independently (please also add an explanation in the documentation here: Merge | Docs). I think it’s something that should be configurable in the node. My use case: I had multiple cases in which the Merge node triggered nodes that were not supposed to be triggered (usually in an unused path of an IF node). I think it would be beneficial to add this because: It gives more control of the Merge node, in …

[ari]

Thank you for the clarification, @jan! Based on this, I switched approaches from Switch-and-Merge to iterating over items using SplitInBatches, and was able to solve my problem.

[jan]

Glad to hear that it was helpful and you found a solution. Have fun!

[Nelson_Paz_y_Mino]

Hi, Ari. Would be great if you can share the alternative. I’m struggling with a Switch-Merge solution and I cannot figure it out. Thanks.

[ari]

@Nelson_Paz_y_Mino Looping like this feels wrong, but at least it avoids the problem.

[Nelson_Paz_y_Mino]

Thanks a lot, I found that calling other flows from my flow with simpler code and specific tasks also resolve the problem.

[jan]

Fyi there is also an open PR about the Merge-Node behavior which will fix that issue once merged (planned with n8n version 1.0).

[jan]

New version [email protected] got released which includes the GitHub PR 4238.