Case SWITCH End (Flow Variable) Unexpected Behaviour

The nodes in the two scenarios (refer screenshot) are the same except for the node order of the second and third inports of the Case SWITCH End node.

Could someone help to explain why the resulting value of var_switch is “false” for the first case and “true” for the second case, even though the “Use first non-inactive port” is selected?

Workflow attached:
Case SWITCH End Test.knwf (23.8 KB)

Thank you for your help!

1 Like

Hi @tjmj,

I believe it’s because the same variable is separately defined in two active parallel streams, although I agree “Use first non-inactive port” seems like it should just take variables from the top input.

When I ran a similar test with only one active input, I got expected results (see below).

1 Like

Hi @sforesti,

Thank you for testing it out. The workflow I provided was a simplified version of a larger workflow. The original workflow has multiple active ports connected to the SWITCH End.

With multiple ports active, this seems to be a bug.

1 Like

I have re-attached the workflow here as it seems that the one in my first post is invalid.
Case SWITCH End Test.knwf (24.0 KB)

Just a update that KNIME Support Team has confirmed that this is a bug.

The reference number is currently AP-14348 (the development ticket number is subject to change).

We came across this issue at @Vernalis when we first wrote this node internally many years ago. Unfortunately it’s an unexpected behaviour which is baked very deep into the KNIME core from my memory of the situation - and one that is unlikely to change as it would break a lot of existing things.

The workaround, although a little clunky, in this situation is to user a Variable to Table Row node at the end of each branch, then use a conventional End IF node, and then extract your variables again using a Table Row to Variable node

Steve

3 Likes

@s.roughley
Great solution! Thanks a lot for this! I will use this pattern in the future. Hopefully, the bug will get fixed, soon.

I did it like shown in the screenshots 1 & 2. Important is to set all the variables to “Enforce exclusion”.
I used a metanode instead of a component because to my experience putting a inactive port connection inside the component would make it inactive (3rd screenshot)

outside the metanode


would not work

2 Likes

Nice trick - and good point around the use of metanode/component :slight_smile:

Steve

2 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.