I am submitting this here in the forum - i believe this is an issue (rather than a feature), but please help me if this behavior can be overcame anyhow, as many times it causes headache.
The issue can be more easily explained by images:
Very simplified workflow: 3 metanodes. In this example, the first one holds all the parameters loading, and there are 2 distinct data loaders.
Parameters metanode: two separate branches serving the 2 data loaders. Some manipulation between the 2 sets of parameters.
==>> As 1st screenshot shows, the data1 loading is running, the data 2 is not. As the 2nd screenshot shows, the data2 parameters are loaded (nodes green).
At this point, when we try to reset the data2 parameters, it is not possible, even though there is nothing running connected to this branch.
It is obvious why former nodes connected to actively running nodes cannot be reset, but it is not the case here, still many operations are blocked.
Does anyone happen to know how to fix this?
I assume this is connected to metanodes - inactive branches are seemingly active for the underlying engine handling the resettable/non-resettable properties of nodes. Restructuring all similar cases in all our solutions from metanodes to expanded many-many nodes is not really an option unfortunately, and also logically would not make sense (hence metanodes are used).
Thank you Iris for your reply. I added 3 screenshots about the workflow (3 metanodes), and the details of the 1st one.
The issue can be easily replicated with any metanode, having 2 or more connections. When any of the external connections has a running node, the other parts of the metanode cannot be reset, reconnected, any modification done --> please see on screenshot #1 that only something connected to the output#1 of the “Input parameterization” metanode is running. If you check the details of this metanode (screenshot#2), you will see that the bottom branch is blocked as well, which has no relation with the running nodes.
I hope this clarifies - let me know if not, so i will try to save some example .knwf without exposing sensitive data.
Another great example is when you run several metanodes connected to one main one, and at the main one, in one branch there is an error, which stops processing of that branch obviously. When trying to fix error in that branch, modification cannot be applied, as “has executing successors” - which is simply not possible, as formerly there was error which stopped all subsequent nodes anyways.
I did open a feature request for this one here. You are right this is unconventient in case of long running workflows. Let me wait for the developers feedback, if this is something which can be easily changed.
Thank you Iris, this is very helpful.
Do you still need me to compile some example workflow, or the developers are now clear on what the issue/intention was here?
Bests,cs