Case Switch Flow Variable Problem

[irene_x]

Hello,

In the description of the case switch end node, it says that for existing flow variables, regardless which branch is active, the case switch end will always collect the value from the top branch. Since it always collect from the top branch, then if I modified an existing flow variable within the case switch, the case switch end might not capture this change. I am wondering is there any way to fix this or are there any alternative nodes that do not have this issue?

Thank you.

[aworker]

Hi @irene_x

Did you try it and got the expected behavior described in the -Case Switch End- node help ?

I’m asking because I tried myself right now and the behavior is different to the one it is described. Both variables coming from different inputs of the -CASE Switch end- node are propagated to its output port.

In the example below I have created different variables depending on the branch. Variables from -CASE Switch end- node input ports are propagated if the branch is active. If both branches are active, then the variables from both branches are propagated:

20221221 Pikairos Case Switch Flow Variable Example with Variables Propagation...

Hope it helps.

Best,
Ael

[irene_x]

Hello,

Thank you for your reply, in the example that you provided, it is creating different variables in the two branches, this will not cause any issue as said in the description. In my case, my flow variable is created before the case switch start, and I am modifying the value of the variable within the case switch, the value of the variable will differ depending on which branch is active. The difference is in the example the variables are created within the case switch but for me the variable is created before the case switch. This is when the problem comes in, when the variable is not created in the case switch the switch end node will always collect the value from the top branch regardless which branch is active.

Thank you.

[gonhaddock]

Hello @irene_x
I don’t know if this description still valid for updated functionalities in version 7.0; but the description in deprecated node (variable dedicated) was clearer from my view:

I have a workflow working as expected when using both, v7 and deprecated one. In my case flow variables from widgets are executed only in the active branch, as you can see with v7 node.

BR

[aworker]

Hi @gonhaddock

@irene_x was mentioning the the -Case Switch End- node that is for tables. In your case, you are talking of the -CASE Switch Variable (END)- node, which is not the same.

I tried the former node and the variables are only propagated forward from the active branch(es) regardless of whether it is from top-most port or other.

Maybe I’m missing something ?

Best,
Ael

[gonhaddock]

@aworker
in V7 there is only one node for all the cases. You can select the type of port that you want to add from the ellipsis. So this node is replacing all the functions and I didn’t notice a specific port type in the first post. However the variables passing function should work in the same way regardless the type of port.

You can see the same ‘CASE Switch End’ node in my lower image.

Anyhow, I’m just sharing my observations about variable behavior, and description’s redaction.

BR

[aworker]

Hi @gonhaddock

Depending on what I select in the component configuration of my posted workflow, the 1st or 2nd input port variables arriving to the -Case Switch End- node are propagated.

Variables from 1st switch input:

|targetColumn (STRING: class)|class|
|predictionColumn (STRING: Prediction (class))|Prediction (class)|

Variable from 2nd switch input:

|addFoldId (BOOLEAN: false)|false|
|Component Context|

Could you please check this in my workflow ? Again, maybe I’m missing something myself on what is going on

Best
Ael

[LukasS]

Hi there,

I think we all agree that the nodes (both, CASE Switch End and CASE Switch Variable (END)) work as intended and as the description suggests: flow variables are merged from the top, regardless of the in-/activeness of the branch. This means, that all flow variable end up at the output. The confusing part is, that if you modify a flow variable in one branch, i.e. two of the branches hold the same flow variables, but with different values, always the top value will be taken - again, regardless of the in-/activeness of the branch.

Albeit being as expected, this is counterintuitive and not at all what one would expect. Unfortunately, this is a design flaw in how flow variables work and changing this behavior would mean to break backward compatibility quite dramatically. It’s still great that you raise this issue, so that we can estimate its priority.

So, coming back to @irene_x’s original question “Is there any way to fix this?” - kind of. You can use Variable to Table Row, a regular CASE Switch End node and Table Row to Variable node. This gives the intuitively expected result (that is, taking the flow variable value of the active branch). However, it adds quite some nodes to the workflow and again all flow variables will show up at the output node, since there is no Flow Variable Filter (yet).

The Math Formula (Variable) Node sets x to 99 and is later deactivated to illustrate the case. (If you want to play with it: Flow Variable Confusions – KNIME Community Hub)

“Are there any alternative Nodes?” - unfortunately not, since this is from a technical perspective not easily possible right now due to how flow variables are designed.

I’d thus recommend creating new Flow Variables instead of “re-using” old ones. Since components are scopes for flow variables (flow variables from the outside of components can be blocked, and propagation to the outside can be blocked), I can recommend these to control the amount of flow variables.

I hope that sheds some light!
Lukas

[supersharp]

Thanks @LukasS for the walk through. As you rightly mentioned, the overwrite of any flow variables changed in any branch is very counter intuitive.

I tried the method of generating dummy variables in certain branches within the case switch, and then a try catch where I renamed these back to the original variable names (and disposed off the dummies at component output). The same set of variables are being addressed in different screens, and we need to retain the value even if out of the second case screen.

This seems to work ok, though the Server gives an ugly warning error message with the try-catch failure. Any suggestions on how to switch off this warning to make polish this up - without recreating dummy variables in ALL branches?

[LukasS]

Hi @supersharp,

interesting that the caught error shows up in your WebPortal - this should not be the case. I tried to build a similar example, but no error shows up for me given it is within a try-catch-context.

(uploaded here: Try-Catch in WebPortal – KNIME Community Hub)

I don’t know exactly what I did differently to not get the error - maybe you can send be (parts of) your (anonymized) workflow so I can investigate?

Meanwhile, you can use a try catch block inside of the Variable Expressions node á la

try {
  variable("x1")
} catch (error) {
  // variable does not exist
  99
}

(it understands JavaScript) - then, the error is already caught in the node, and the workflow is error free.

Kind regards,
Lukas