I recently started getting more into Long Running Workflows and Persistance. While trying to build some sort of error handling for my workflow I noticed a couple of quirks, that maybe somebody has experience in dealing with.
I have a Long Running Workflow from UiPath.FlowchartBuilder.Activities as the main entry point of my project and i created a second Long Running Workflow which i set as GlobalHandler in hopes of being able to handle errors occuring in my workflow also in a flowchart fashion. I know about the detached error handler in Long Running Workflows, but unfortunatly that one doesnt allow the actions of Retry/Ignore/Continue the same way a Global Handler does.
I was hoping to do the following:
Which would basically allow to retry certain errors with a delay (incase some service is currently not available). After a number of retrys or incase of non-retryable errors a task is created for a dev to look at and the process is suspended until that task is finished. Uppon finishing the task the dev can choose an action of retry or abort to retry the failing activity again (hoping some error was fixed) or stop the process.
Now the big catch: From what i could tell, any sort of persistance activity inside the GlobalHandler makes it so the global handler is not even executed upon an error.? The needed argument of type ExceptionHandlerArgs for GlobalHandler is also not serializable, which would probably mean: even if the GlobalHandler gets executed its value is lost after the pause, which also means information like the retry count is also lost.
On a similar note: It would be lovely to have support for multiple entry points into a Long Running Workflow. In case of an error this would allow the supporting dev to restart the process from different points, depending on where it failed. (Im aware i could build something similar with an input arg and a switch to go to different places, but multiple bpmn start nodes would be a lot nicer to look at)
Let me explain some nuances of the global exception handler when working with Long Running Workflows. This is registered as a bug, but i think sadly with the focus on Maestro this product isn’t getting the love it deserves as its been outstanding for a long time.
Basically the global exception handler will not fire if the activity erroring is on the very top level of the canvas, which is a problem when using error end events, integration service activities and in your case.
Yours has a simple workaround, wrap the activities in a sequence instead of directly using assigns or tasks etc. The persistence is not the issue here. The global handler fires fine with them, you just need some sequences as wrappers.
I think its also worth you learning about error boundary events too.
I would not model this with the global error handler, it doesnt work well because it acts as a first chance exception handler.
What I would do is wrap the activity in a retry scope, then rethrow the exception once it hits the limit, then using an error boundary event direct the flow to the relevant escalation path.
The global error handler can be useful still however, but I find it only useful for logging.
Another missing feature in the long running workflows in the Detached Error Handler behaviour since the exception that triggers it doesnt get passed to it.
That can be mitigated, somewhat, by using the global exception handler to log it, notwithstanding the top level limitations mentioned.
The user wants to handle errors in a Long Running Workflow. If an error occurs, the workflow should retry it a few times. If it still fails, it creates a task for the developer. The developer can then choose Retry or Abort. The main concern is whether the error details and retry count are preserved after the workflow is paused and resumed.
Thank you so much for your input! You are right about the Exception Handler only working if the activity itself is wrapped in a sequence. Unfortunatly i was already unconsciously doing this. Turns out the issue i was having is independent of Long Running Workflows and already occurs when using a normal workflow and a Global Handler with a Persistance activity inside.
Simply having the “Resume after Delay” activity there causes the GlobalHandler to not be executed. After commenting it out the GlobalHandler works as expected.
