Call Workflow Service different behavior when executed consequitively

Feedback & Ideas
1

given the batch removal, i had a look into the call workflow service for local orchestration and immediately ran into weirdness:

the workflow input is obvious the handover point. but why are the nodes prior executed once, but not on subsequent calls? totally inconsistent / bad state management ?!

Conseq Calls.knar (117.0 KB)

WARN  Java Edit Variable   4:2        ##################
WARN  Java Edit Variable   4:2        before input
WARN  Java Edit Variable   4:2        ##################
WARN  Java Edit Variable   4:7        ##################
WARN  Java Edit Variable   4:7        after input, before output
WARN  Java Edit Variable   4:7        ##################
WARN  Java Edit Variable   4:10       ##################
WARN  Java Edit Variable   4:10       after output
WARN  Java Edit Variable   4:10       ##################
WARN  Java Edit Variable   4:7        ##################
WARN  Java Edit Variable   4:7        after input, before output
WARN  Java Edit Variable   4:7        ##################
WARN  Java Edit Variable   4:10       ##################
WARN  Java Edit Variable   4:10       after output
WARN  Java Edit Variable   4:10       ##################

caller

image
image734×193 6.38 KB

callee

image
image799×515 27.4 KB

2

Hi there,

that is actually on purpose, and will help with speedup.

The idea, or the original trigger, for calling workflows, was to repeat a workflow multiple times. Think about Scoring Data Points. In Scoring you than would need to only execute the predictor nodes, but you do not need to reload the data every time. Or you do not need to do the preprocessing every time. This is why only nodes after the workflow input are executed.

Would it work for you to queue all nodes which need to be reexecuted after the Workflow Input node?

1 Like
3

is that unexpected behavior documented somewhere?

Why are the nodes prior the Workflow Input executed just once, but the nodes after Workflow Output executed every time (following your explanation, this does not make sense if you essentially want to reduce overhead but executing only the minimal relevant path for maximum efficiency) ?

4

Briefly checked the node description, but it is not explicitly mentioned there. Totally agree, it is unexpected that nodes after the Workflow Output are executed.

I would be curious about your usecase, why would you need nodes before the Input and after the Output? Maybe we can find a solution together.

5

A)
I need a reliable local-only execution with predictable behavior.
Since your team just gutted the batch execution, I started looking into other options that you offer AND fulfill the criteria of being local-only. I don’t have need for a machine to do non-deterministic actions. It is annoying enough to deal with the bugs (of Knime AP), shortcomings (of Knime AP) and non-deterministic aspects from outside of Knime AP.

B)
the nodes before the input where added for the general setup. As you know most of your nodes require some data to be present to configure them. Nodes after the output where set up because the Workflow Output node contains an outbound connection. Hence, it’s reasonable for me to test the (intended / undocumented / unclear) behavior. Especially before I consider porting my setup.