I have recently updated KNIME from 4.3.0 to 4.4.1 and one of my workflows which was previously working now fails to run with the following error:
Unable to merge flow object stacks: Conflicting FlowObjects: Try-Catch Context vs. <Inner Loop Context (#execute) - Owner: 0:115:0:66> (loops/scopes not properly nested?)
I have looked into this and I have managed to narrow down where this error is coming from. My workflow is checking the status of a job via REST, when the job is no longer running it checks if the job status is complete and if so will proceed to make REST call to download the results.
I have a Java IF to check if the jobStatus is equal to complete and if it is it proceeds to the get results component which downloads the result. This get results component has a loop with try/catch block in so the GET request is retried a few times in case of a connection error. Somewhere between this Java If component and the retry loop in my get results component this error is occurring.
Please find attached an minimal example workflow (just making REST requests to google) which for me replicates this issue when running on KNIME 4.4.1. Running this workflow on KNIME 4.3.0 works without the aforementioned error (it does give some warning as I created the example workflow in KNIME 4.4.1 but the workflow runs fine with no error).
UnableToMergeErrorReplicator.knwf (38.2 KB)
Here is a screenshot of the workflow showing the warning/error:
Hi @adamislip , I don’t see any error from the screenshot. There are only 2 warnings, and they should not stop the execution. Sometimes you get warnings simply because some items are missing at that time simply because some nodes have not run yet.
All of your nodes seem fine in the screenshot.
Yes I described these as errors where I did mean warnings. However, these warnings do seem to be stopping my workflow. In KNIME 4.3.0 this workflow will run from first component to last whereas in KNIME 4.4.1 this workflow stops in the try/catch loop.
In my workflow I have the try/catch loop piece in a component and this component shows a red-cross, I’m presuming that means something inside this has failed. However, I only see the ‘Unable to merge flow object stacks’ WARN messages.
Hi @adamislip , can we see what ran and what did not inside that component? You can hold down the CTRL key and double click on the component.
Looking inside the component I see no nodes with the red error cross. I only see that the Catch Errors node and all subsequent nodes are in the not executed state.
Running the same workflow in KNIME 4.3.0 I see no warnings and the workflow executes fully. Inside the component all nodes have been executed
Best Wishes, Adam
don’t know if you have already solved or found a workaround for your issue? Anyways I have taken a look at it and can not really figure out why but seems lower branch in Try/Catch node is causing this behavior. Possible solutions/workarounds:
- wrap entire Try/Catch sequence in a Component
- if possible, don’t connect Try node with lower branch but instead build your own table by using Table Creator (and other nodes if necessary) to feed second input port of Catch node
Wrapping the try catch in a component does work for me so I could employ this as a workaround in my workflow
I’m don’t think I can currently use the Table Creator to feed the bottom port of the catch node at present as I am passing the failed input through to another component.
During my testing one workaround which did seem to stop this from happening was changing IF branching before going to the try/catch loop. Instead of using the Table Row to Variable and Java IF, I instead used the Java snippet to set the port depending on the column value and then use the IF node with the port set using a variable I created in the previous snippet. This seemed to stop the issue occurring but I have no idea why. See below:
Workflow fails when using Java IF:
Workflow succeeds when using Java Snippet and IF Switch nodes:
glad workaround is working and even better that you have found another way that also works
Regarding why hope someone with more knowledge will take a look at this behavior and explain it or take necessary action to fix it
thanks for reporting this issue! We qualified the problem and added it to our ticket system.
It’s quite an intricate problem which only occurs due to an interplay of multiple conditions (to give you a rough idea: the minimal workflow to reproduce the problem must (i) contain a loop which in turn (ii) contains a workflow with a node that ‘merges’ two workflow-branches whereof (iii) one branch contains a node which returns no data-table specification at configure time and (iv) has a successor node; and (v) all those mentioned nodes need to be ‘inactive’ when the entire workflow is reset).
If any of the condition is not met, the problem is gone.
This also suggests another workaround: make sure that the
GET request with retries-component is ‘active’ in case the workflow is reset (i.e. the
Java IF (Table) needs to be re-configured to activate port 1 if the ‘jobStatus’ is missing - if I’m not mistaken).
Thanks @hornm (and also to @ipazin and @bruno29a for looking at this also)
I think your explanation also explains why when I replaced the
Java IF Table node with a
Java Snippet and
IF Switch it worked, which was puzzling me. Resetting the workflow with the ‘JAVA IF’ node means the
GET request with retries component is inactive when resetting the workflow.
When using the
Java Snippet and
IF Switch the
GET request with retries component is active when the workflow is reset.
Hello @adamislip, I just want to let you know that this problem is fixed and released with Analytics Platform 4.5.0.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.