I think I have encountered a bug in the way KNIME determines whether a node is executable or not. It seems that whenever a bare node follows a metanode that is again preceded by a bare R/Python snippet node, KNIME thinks that the final node is not executable. This problem disappears when the R/Python snippet node is replaced by a different node. More strangely, the problem also vanishes when the R/Python node is collapsed in a metanode:
One of the awesomest things about KNIME is that it able to figure out automatically what preceding nodes need to be executed to obtain the results of the selected node; but in this case, it seems to fail. Example workflow below.
Thanks for your analysis and detailed explanation of the behavior. I would agree that the behavior is not accurately captured in the metanode because it serves mostly for visual organization in the workspace. After testing your workflow, I found that when converted to a wrapped metanode, it acts consistently for what is encapsulated, so my recommendation would be to utilize wrapped metanodes when wanting to accurately represent data & functionality, while just keeping metanodes for organizing the workspace.
Thank you for your answer, but i do not quite understand what you are saying. You say regular metanodes are only for workflow organization; that is, they are purely cosmetic. But why then does this purely cosmetic feature influence whether or not a node can be executed? That is a bug, right?
Or should I simply start regarding normal metanodes as “deprecated” and only use wrapped metanodes?
For the bug classification, it depends on whether or not that was the intent of the functionality.
For now, I would go with your last statement as a good rule to follow when wanting to encapsulate functionality. This post has some good points that might articulate it even more: wrapped metanodes versus metanodes
Do you perhaps know if one of your colleagues can tell whether or not it is intentional? My workflow (https://www.sciencedirect.com/science/article/pii/S0003267018309346) includes a lot of (nested) regular metanodes and I am afraid that potential users may get annoyed if they select one of the last nodes in the chain and it cannot be executed because of this effect/bug. I could convert every single one of the metanodes to wrapped metanodes but I am afraid that this will take quite a lot of time since they are not fully equivalent.
Quoting the previous link forum post, I think you can see the intention:
We first had MetaNodes only. We than introduced the wrapped versions, because those should get a lot more features and we still want to stay backward compatible. Also the wrapped nodes can be used for our webportal, there each wrapped node is one page on the webportal.
I see what you are getting at and do agree it is annoying to have to convert all of those or have a bad experience for potential users and will pass along this feedback.
My own two cents here: I think this bug represents a large barrier to entry for novice KNIME users. As part of my efforts in KNIME training, my experience is that it can be a struggle to get new users to understand the idea of a node and that you can manipulate and execute any node by right-clicking. Very quickly (usually day 1) users will come across this problem where certain nodes are not executable since they come after a metanode. This behavior goes against the fundamental concept of the entire KNIME environment and thus new users conclude that KNIME is “junk” or that it is way too complicated for them to understand. These people walk away and don’t end up learning how to use KNIME. I have observed this over the past 5 years and think it is finally time to fix this bug.
Tnx for your feedback! To be honest I never experienced this behavior and thus don’t consider this a large barrier (or at least I don’t remember or the reason is that I execute either all nodes either one by one ) Besides @Aswin example do you have any example of your own that would be representative/keeps occurring on training?
Additionally seems to me this causes issues only in development phase. Once workflow is deployed/in production this has no effect on executing.
I can confirm @joshuahoran 's experience. When I was a Knime newbie, whenever I had a particular arrangement of nodes and metanodes, I could no longer right-click and execute downstream nodes, which was somewhat frustrating. This happened quite often. Of course, I could always select “execute all”, but that is not always an option when the workflow gets large or processes large amounts of data.
It might not be a problem when the workflow is “deployed”, but in my case development is all I do because I mostly use Knime in the same way other people use Jupyter or RStudio notebooks: a convenient data processing and analysis workbench. I can’t be the only one who uses Knime in this way.
The problem may also arise with other nodes than the R/Python nodes that I mention in my first post. One of the endpoints in my “main” daily workflow produces a volcano plot. Suppose a student of mine tries to use the workflow on his data to produce a volcano plot. He enters the data in the beginning of the workflow and tries to produce to produce the volcano plot by right-clicking on the volcano plot metanode. Bummer: he cannot right-click and execute that metanode. Student is confused and disappointed and does not understand why his supervisor is so excited about Knime. He throws the towel and returns to the Excel sheets he know best. We don’t want that to happen, right?
However, it turns out that the node that is just two metanodes upstream from the volcano plot node CAN be executed by right-clicking it. The are no R or Python nodes in those metanodes. I will try to isolate this specific occurrence and make another example workflow, if that helps.
Here i have another example, one that does not contain any Python or R nodes. It looks a bit odd because it is derived from a part of a much larger workflow. The last node cannot be selected and executed, even though the workflow as a whole can be executed.
I work in biotech where the workflows pushed to end users are typically a mix of R, python and normal KNIME nodes. The workflows are HUGE and therefore the informatics guys collapse much of it into metanodes. As described by Aswin, this means that nodes after metanodes cannot be executed by themselves. Further there are sometimes a few different branches in the workflow that the user can execute separately and therefore they are discouraged from hitting “execute all.”
The workaround that has been in place for the past 5 years is to place a floating table creator node next to each of the terminal nodes in a workflow. To execute a workflow branch, new users are trained to:
Make sure the Table creator node is reset
Select both the terminal node as as well as the nearby table creator node (Teach shift-click to help here)
Right, this is what new users say when the come across this bug; and they walk away thinking that if something so simple doesn’t work, then it isn’t worthwhile learning such a broken piece of software.
Well I would not call Knime a broken piece of software But of the bugs that I reported over the years this may be the one encountered by the largest number of users. Whether a particular user is confronted with it or not depends, I think, largely on the workflow building style/habits of that user. That’s why some users may never see the bug, while other users may encounter it all the time. But it is hard to pin this bug down, that is why it is not reported so often I think.
I personally wouldn’t call it broken either – I use it for nearly all of my day-to-day work. However, among the people I try to teach to use the software most reject it due to the perceived inability of the software to perform even the most basic functions correctly.
Just to drop info here as well that you shouldn’t experience this kind of behavior no more as fix was implemented with KNIME 4.2. https://www.knime.com/changelog-v42 (AP-9721)
I already had the feeling something changed there… Suddenly I could simply select the last node in one of my workflows and click “execute”, which was not possible before. Much more intuitive! Thanks guys!
p.s. that must have been a hard bug to solve considering the low bug ID number as compared to the all the other solved bugs!
) Besides 
But of the bugs that I reported over the years this may be the one encountered by the largest number of users. Whether a particular user is confronted with it or not depends, I think, largely on the workflow building style/habits of that user. That’s why some users may never see the bug, while other users may encounter it all the time. But it is hard to pin this bug down, that is why it is not reported so often I think.
