+1 on this error. What is the status? Any workaround?
Sorry to push this, but I'm just hitting this issue again and again and it's extremely tedious to work around it somehow.
Is there any news on this?
Or are there any workarounds?
Pushing again, as the thread didn't appear in the forum overview :(
Sorry for pushing this old thread but I am currently experiencing the same bug. Has this issue been fixed or is there a workaround available?
Same for me “Active Scope End node in inactive branch not allowed.”. Trying to cope with corrupted archives used by an unzip node and if that fails move the corrupted files.
thank you for bringing this up. Unfortunately we did not get this fix till date. I will push this ticket for both of you.
Best wishes, Iris
My workaround at that time was to move the part of the WF which could potentially fail into a separate sub-workflow which was triggered by a “Call Local Workflow” node. This ensures a new, separate, and clean scope. The structure looks like that (the meta node after “Call Local Workflow” either processes the result or performs some error reporting, based on the result from “Call Local Workflow”)
I finally came to this approach after wasting many, many hours and attempts and being very frustrated. But at the end it still worked to my satisfaction. (frankly, I am not not sure however, whether I will use KNIME in the future to create such workflows which require extensive error handling as this is just too fiddly, probably not so much KNIME’s priority, and I could have solved my above mentioned issue by code/script within 1/10 of the time)
I managed to get it working. Predominantly because I’ve chosen another try node to use variables.
Thanks for everyone of your feedback!
I have the same error messages . Active Scope End node in inactive branch not allowed It occurs in a inactive branch (Empty Table Switch) within a Loop End node.
When doing a mouse-over on an output port I expect (Inactive Port Object), but that’s missing after the Parameter Optimization Loop End
Any idea’s how to deal with it,workaround? Is this still an issue as mentioned in this thread?
I have this same issue in v3.7.2 (unable to upgrade to v4 yet), seeming caused by a loop inside my Try/Catch with the error occurring inside that loop. If I move the try/catch inside the loop start and end nodes, the error goes away. Here is the fix I came up with - requires two try/catch, and a breakpoint which will propagate an error inside the inner loop to the outer try/catch to enable to out loop retry.
Worry not. The original issue is still not fixed in recent versions.
with Analytics Platform v4.2.0 try-catch-blocks can finally handle component failures, too. That is, errors occurring within a component will be caught and the workflow execution continues with the alternative branch. Although it doesn’t directly solve the problem at hand (i.e. failing loops in a try-catch-block - an issue that is still on our list to be solved) it offers a straightforward workaround: by wrapping the potentially failing loop inside a component (or even the entire sub-workflow between the try- and catch-nodes).
That’s good news!
Hi - So i tried this also, i have a failing google analytics query node failing within a loop, i put from the loop start to the loop end in a component.
When it fails the catch simply goes red…
what did i miss?
@Gavin_Attard Components are not supported within the Try Catch nodes. That is a open item for us. However it is fixed for the 4.2. release
Thanks @Iris - Oops should have checked the version number… doh…
Good news though.
Been crackign my head over how to solve this all morning.
I now got to a stage where i can output all iterations, and the one’s that failed append to the loop output table by putting a try catch around the variable feeding the GA query tool and the query tool.
Now i need to figure out how to pass those failed attempts back to the loop, i think i am almost there. the answer lies with the recursive loop i’m sure, just need to understand exactly how that works, i.e. how can i pass just the rows i want to have re-done back through.
WoooHooo!!! Success - solved the GA Query / read timeout issue (or any other error it may generate).
Will post a full solution in a separate thread in the mean time here is a preview of the solution.
This can be used for any loop where failures need to be re-passed or re-attempted, for which the use cases in this thread allude to.
any news on the original problem because from, I am afraid to say, 2017? I just faced it again even with the Try Variable Node I once found to mitigate the issue.
Maybe it’s indeed fixed but not for the community Benchmark nodes?
ERROR Benchmark End (Memory Monitoring) 0:1206 Active Scope End node in inactive branch not allowed.
I am too running into this issue.
Any ETA when this will be adressed?