Job is getting stopped after getting Application Error

I am using RE Framework with Queue. In case of Application exception, my JOB is getting stopped with an error as shown below and also setting the Queue Item status as Retried. I am expecting the Job to mark the Status as Failed and continue with the next transaction.

Error thrown: RemoteException wrapping System.Exception: Job stopped with an unexpected exit code: 0xE0434352

Am I doing something wrong. Please suggest.

Hi @sumit.tyagi

In config file under ‘Constants’ sheet, please change the ‘MaxRetryNumber’ value as 0.

So that whenever application exception thrown the transaction will mark as Application Exception and will not retry

Also it will process the next transactions.

Thanks. Happy Automation.

Feel free to reach us at any time if you are having doubts.


Thanks for your reply. I have already used Max Retry as 0 in Performer’s config. Any other issue that could happen?

Sumit Tyagi

It has to be greater than 0 only then the robot will retry the same transaction which failed with a system exception

And status will be usually set to failed
Go to Process state and you can see a TRY CATCH Block
In that activity there is a section called FINAL

Get there and you can see a process being invoked named set transaction status
Inside that you will find a flow chart and get into the block if systej exception is true

There you can change the transaction status with SET TRANSACTION STATUS activity

Cheers @sumit.tyagi


Thanks for your reply.

As I mentioned in original post, I am using Queue, so I am using Queue Retry and not the retry mechanism of RE framework(so set the max retry as 0).
Also, in Set Transaction, I haven’t changed anything so it by default it is set the status as Failed. But still somehow, the status is getting set as Retried in orchestrator.

I have replicated it in the default RE framework where I only made 2 changes:

  1. In config file, set a Queue Name (any Queue with test data in Orchestrator)
  2. Throwing a only System exception in Process transaction. No changes other than that.
    It is moving to next transaction but it is still setting the Queue item status as Retried instead of Failed. PFA (6.9 MB)

Sumit Tyagi

Look at the queue in the orchestrator itself.
There is also a retry flag there which can only be set during queue creation, I believe it is unchangable when editing a queue).

Example: if you enter 1 item in the queue that is throwing an exception

With max attempts set to 1 → it is set to failed
With max attempts > 1, the first fail(s) will set to retried, and a new item is created with the same data. In the last allowed attempt it is again set to failed, assuming the exception still occurs.

The queue settings in the orchestrator:

Hi @Jeroen_van_Loon

Thanks for your reply. I am using Auto Retry with value 1 only. It is creating a New Queue item when an exception occurs but still the original item is shown as Retried instead of Failed.

Sumit Tyagi

That is correct.
The first item is marked as retried, since a duplicate is created that is the retry.

Basically it states: “I failed, but I am not the last one, after me a new attempt is done”
And it rhymes, so it is true… :wink:

So for your consideration: each retried queue item is a failed item, that has been retried later.
This is just how the mechanism works. (And it has a few reporting benefits as well)

1 Like

Thanks for explaining it.

Also, I was able to find the issue due to which Job was getting stopped completely and not taking the next transaction.
It was due to a DT which was having 2.5 Lakhs records in Init phase after reading a file in 1st run, after which if there was application error, it was going again in the Init phase to read the file again and re-write the same DT again with same values. So this was the main cause.
I moved that reading DT code in config first run part and it worked. Now it is not trying to rewrite the DT in Init phase in case of application error and hence able to take up next transaction.


This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.