Activity to set a Job State to "Faulted"

Currently, if you have graceful exception handling in your process, even if your process has errors and technically “Failed” its intended goal and if your Try/Catches succeed in catching all the errors, the Job State is still listed in Orchestrator as “Successful” despite having failed the intended goal because the process technically completed from start to finish without unresolved errors.

We need an activity that we can include in a Catch where we know the Job State has faulted so we can override the Job State in Orchestrator as “Faulted”, despite having caught the error because we want to avoid an error popup for the end-user.

Specifically, from an Orchestrator-monitoring point of view and analytics, we should not be seeing “Successful” jobs if they were in fact Faulted.

Per my understanding this can be done currently.

After handling your exception simply use a Rethrow activity to rethrow the exception. Assuming you don’t wrap this in an additional try/catch this will not be caught and will display as Faulted in Orchestrator. This allows you to gracefully recover but also to properly update the Job status.

Does this cover your need?

This Rethrow would occur at the end?

Yes. Let’s say that to handle the exception we wanted to close the application and send an email to the business subject matter expert. We might do something like this:

The application would be closed and the email would be sent. Then, the Rethrow would cause the job to appear faulted.

What if I want to do additional processing AFTER the exception was caught and the email was sent, but still show the job as “Faulted” in the State when looking at Jobs in Orchestrator?

Any uncaught exception will cause the job to be “Faulted”. As long as you do all of your processing BEFORE throwing or rethrowing an exception you will be fine.

@DanielMitchell Yes, this is the crux of it. So in your example, if I continue with more activities, more processing, etc., and finally get to a place where the job is going to end, if I put a Rethrow there, it will cause the exception and mark the job as faulted, right? Even if processing did another 20 activities after, right? If that’s the case, great. However, if it is, what happens if there were no exceptions, and you call a Rethrow?

1 Like

Thank you, I appreciate the response.

However, this really would not work if you are also using a Global Exception Handler. The Rethrow triggers the Global Exception Handler, and it will retry the activity (Rethrow) and Try Catch (default 3x) until it goes to result = errorAction.abort. This would result in an error popup (which I want to avoid for the end-user) - or even in unattended automation, the popup onscreen might hinder other scheduled unattended automation.

@x.Rei.Ai.x You seem familiar. I think we spoke on this before where you wanted this and I didn’t think it was possible. Seems like I was wrong! :smiley: I just didn’t know about this method. If not you, then sorry!

I wonder if you could have one final Rethrow in the Global Exception Handler (by this you mean wrapping the entire code in a Try Catch, right?) Could you put that as the last thing in there? Maybe in the Finally? Can’t remember if you can place it in Finally.

I am excited about this prospect as well, b/c like you, I too wanted this functionality, but resolved to it not being possible…until this post…

1 Like

haha, yes I think we bumped into each other in a previous post. I don’t remember if it was regarding this specific issue - I think it was something to do with the wait attribute?

But yes, I could put a “Throw” activity into the Global Handler with the errorInfo argument for the details, but, again, this would show an error popup for the user. Maybe there’s just no way around the error popup if we want the job to be Faulted.

I don’t use popups when communicating with the attended user (unless for user inputs). I have a reusable workflow that creates a “Robot Desktop Icon” that shows a callout box and text-to-speech voice to communicate to the user. This is the main reason I want to avoid having an error popup (not to mention unattended automation not needing a workflow to check if there is an error popup before starting its process), and the need to be able to override the Job State in Orchestrator to “Faulted” when the workflow really has failed despite finishing the process.

Ah. Yes. This has been my experience as well. I never could find a way around it.