Issues related to node/component execution within inactive branches

[RKrom]

Last week I opened up a support case related to calling sub-workflows and not being able to see the widgets on the KNIME WebPortal. This has been answered by @Alice_Krebs.

As a workaround we’ve implemented the use of many many case switches to achieve the required results, but unfortunately we came across a big issue, which is the unwanted execution of nodes/components inside components of inactive branches.

In the attachment you will find a test workflow which shows the issue:
Inactive Branch issue.knar (38.6 KB)

The workflow contains 3 branches:

Case switch port 0: Active branch
Case switch port 1: Inactive branch #1 (including the issue)
Case switch port 2: Inactive branch #2 (including the undesired workaround)

The issue is in the inactive branch #1, where the main component is connected to the inactive branch, but the inner component is still being executed. Where the expectation was all nodes/components inside an inactive branch will remain inactive and are skipped during the execution.

There is an undesired workaround for this, which is connecting all nodes/components within another component to the flow variable output of the component input:

This way the inner component is inactive and will be skipped. This brings additional complexity (and it hurts the eyes for components containing many nodes) when creating components. We have introduced KNIME for little bit over a year and basically we can’t re-use many of the 100+ components in the way they are created now in combination with inactive branches (e.g. with case switches and empty tables), as using these in an inactive branch will either crash the component (1), consume a lot of unnecessary processing/memory power (2), or worst of all lead to incorrect results of a workflow (3).

Is this behavior of the inactive branches as it is intended? Is there a more efficient workaround possible?

I’m looking forward to a solution. Thanks in advance!

Kind regards,
RKrom

[Alice_Krebs]

Hi @RKrom

I understand your issue, and I agree it’s unexpected and definitely not ideal (even more as this is only the workaround).
I have taken this up and will come back to you asap.

Just out of curiosity, how often do your components in components include data import? Also, what was your rationale to put components in components?

Thanks for more info!
Best, Alice

[RKrom]

We use components inside components very often. It is not unusual a component contains hundreds of nodes and ~20 inner components doing either small or big conversions. Sometimes those inner components are very simple (few nodes with a single selection or string selection), but others are small workflows by itself (~300 nodes in a single component is the record).

Especially now with the development of the WebPortal we have multiple components inside component as every WebPortal page has to be a component by itself. Inside a “page component” we will have several components, such as: header (repeated every page), footer (repeated every page) and all content (which could be existing of an x-number of component).

The reusability of shared components is the main reason we moved to KNIME. Until now this has been ideal for us and did not cause any issues. Now since we recently started developing more advanced WebPortal workflows we end up in situations where the end-user has to access specific areas of the workflow by use of case switches/empty table switches.

[Alice_Krebs]

Hi @RKrom

Just to keep you posted: Yes, this is unexpected behavior and a bug. It could be theoretically be fixed with 2 lines of code, however that breaks the current execution behavior. So unfortunately this will not be included in the next bugfix release, but needs a bit more work. I have opened a ticket for that (internal reference AP-19271).
We’re very sorry for the inconvenience!

Best,
Alice

[RKrom]

Hi Alice,

Thank you for your response. I’ll keep an eye on the release nodes.
I do want to mention this is very critical issue for our operation at the moment. Do you have an estimate for the bugfix if it’s not in next release?

Kind regards,
RKrom

[Alice_Krebs]

Hi @RKrom

I just saw changes on the ticket and thought I’d give you an update. This fix will be included in the next feature release (version 4.7), which is going to happen in autumn this year (please be understanding that I’m careful here with defining dates publicly).
If you would like more information on this or this doesn’t work for you, please reach out to us via email!

Thanks,
Alice

[RKrom]

Hi @Alice_Krebs,

Thanks for the update and I appreciate the openness on this bug.
I will follow up on this over e-mail, cause a fix in autumn will be too late as this bug impacts our operation significantly.

Kind regards,
RKrom

[BCadete]

Hi Krom,

Indeed this is something that should be addressed as soon as possible. Maybe an hotfix ?

Cheers,