Support for continuing execution of nodes with empty input

I have a workflow where I lookup vendors for some cost details and merge the data to be further processed. The vendors may not exist for all the items.

As you can see, when a certain set of costs come in, and none of them have a vendor associated, The vendor lookup returns no results and the further nodes stop working, including the merge node.
How can I make it such that empty nodes continue to get processed (output will also be null/empty array).

But for me it looks like the problem is that the IF-Node does not return a value for “true” rather only for “false” and that is why it stops. Else the “Get Vendor” would also have a green “1” in its corner.

So the solution here would probably be to connect the “false” output of “IF” to the “Input 2” of the “Merge5” node. Depending on the data you maybe have to change it like removing all the data with a Set-Node before.

Ah think I understood your question a little bit wrong. What I think you propose would not really be possible (or would mean a huge overall breaking-change). Simply doing what I proposed in my previous answer is for that reason the way to go.

But just to be sure. Before you connect it to “Input 2” you have to have another Merge-Node that collects the data from “IF”->false and “Flatten Vendor List” so that “Input 2” of “Merge5” does only have one input connection.

Tried that. The issue is in most cases some items would go to true branch and some to false branch. Tying false branch to short circuit input 2 of merge node wouldn’t really work.

Same situation for including a merge node. In case all cost items have vendors to false branch would be empty and stop execution of the new merge node which would in turn block merge 5.

I understand it’s complicated fix and potentially a breaking change. If it had been a simple fix I would have raised a PR instead. I tried. But I believe it is very essential change without which we have some serious limitations on usage.

Ah ok, yes understand now the problem here.

An easy fix would maybe be to add an option to the IF-Node which always sends items on both outputs. So even if there is nothing for the “true” one, it would still output one empty item.

This is only one case where If actually illustrates the problem effectively so I used it. But the same problem exists with other nodes. As long as execution stops without data, this is going to be a problem.

One fix, if possible could be on merge end. If at least one of the items is ready, we should be able to run the merge. That’s what I attempted but it becomes tricky in that we don’t know when results are available on upstream.

The otherfix could be an option to continue on blank on any generic node; similar to continue on fail or retry on fail options. Which would enable executing on blank input and outputs []. The (1) on top right shows we are tracking execution status independently of output I’m guessing we could use that instead of the output/input to decide the ready for execution bit. This could be tricky on batch operator and downstream where we have multiple executions. I could possibly be of some help if you can show me where to look in the code base.

That what you described as “otherfix” is actually what I have actually already similar on my to-do list. To add a node option “continue on empty”. Which outputs one empty item if a node returns null (which stops the execution).

As I was currently already make some changes to the core I included it directly.

Now each node has now the option “Always Output Data” under “Node”. If it gets set, it outputs at least one empty item on the first output.

Got released with [email protected]

2 Likes

Hey, I had the chance to try it out.
A minor bug: In ‘IF’ node, only the ‘true’ path force outputs data, ‘false’ path doesn’t.

That is not a bug. It is documented like that in the description of the option:

If activated and the node does not have any data for the first output,
it returns an empty item anyway. Be careful setting this on
IF-Nodes as it could easily cause an infinite loop.