Configurable IF/CASE not managing Component Status correctly?

[mwiegand]

Hi there,

I happen to cross a possible issue where the Configurable IF/CASE Switch Node seems to not properly disable the nodes / components in the inactive branch.

No particular error is thrown but due to the inaccurate execution status Knime is unable to proceed processing the workflow. Kind of like a false positive / soft error maybe?

I added the regular Java IF Table Node with ternary statement for comparison. IN the screenshot below you will see the top branhc with a correctly handled disabled branch whereas the bottom with the Vernalis Node displays the issue.

Best
Mike

[Vernalis]

Hi Mike,

Can you tell me what variable type you are testing and what the comparison used is please? It’s not a behavior we’ve seen previously!

Thanks

Steve

[mwiegand]

Hi Steve,

I was just able to reproduce it with the regular Java IF Switch as well. I am testing for:

return $${INumber Rows}$$ == 0 ? 0 : 1;

I also face, but not related to Vernalis, an issue where the same variable is being complained about not existing for Variable Loop Condition End albeit clearly being available.

It almost feels there is a general, erratically appearing regression about Int variables. I know, sounds wired …

Edit: Super strange, there is no warning, no error, Knime simply stops executing

Best
Mike

[Vernalis]

Thanks Mike. I have seen slightly weird behavior from time to time with KNIME when it seems that reexecuting a node has not updated either the output table or a variable value, and I’ve no idea why it happens, and not been able to reproduce it reliably enough to report as a bug. Normally it seems to go away when you restart KNIME, and then not reappear for months. Hopefully! I’ve never figured out cause or cure unfortunately.

At least I’m perhaps not the only person to have seen it!

Steve

[mwiegand]

Hi Steve,

that behavior you described I once raised as well but in regards to null pointer exceptions which are hard to reproduce. Though, this one is less problematic yet still annoying as hell. I have an idea how to attempt to reproduce it and it might be caused by the Parallel Start / End Nodes (just gut feeling atm).

Do you happen to know how I can extract as many details about the execution state for debugging reasons as possible? Curious if there isn’t a node which auto collects all logs, mem dumps etc…

PS: I restarted Knime but the issue still prevails.

PPS: Setting parallel branches to one to eliminate one possible point of failure I happen to notice that the issue still prevails. Further proceeding by adding a grouping column in the GroupBy did not resolved it either. The End IF node simply snaps. I start to believe this is a general bug, wouldn’t you agree?

PPS: Total Face Palm I presumably replaced the component but it was not replaced. Since the naming was identical, well … see yourself

Apologize to the inconvenience.

Best
Mike

[Vernalis]

Ah - dropped right on top but not replaced? Been there.

As far as logging goes - the best bet is the Open KNIME Log option on the View menu.Of course, when you want the most information you have to set the logging to ‘DEBUG’, and then you have reams of it to scroll through (thinks like every workflow you open each node and connection being added, every node you run a whole series of steps etc etc) It would be great if there was a node to read it directly into a table!

Steve