Queue Trigger - Faulted Jobs

Help Orchestrator
,
1

According to the documentation, queue based trigger will only start a process when a minimum number of new transactions are available. What happens if the process faults? Does the queue trigger kick off another job as there are no longer any jobs running? How does the maximum amount of simultaneous jobs trigger setting affect this? Say you have the maximum set to 3 and the queue is loaded with 100 transactions, three processes start and one faults without adding any new transactions to queue (as it faulted in the initialization state). The state would then be 98 existing transactions in queue, 2 in progress with 2 processes running. Will the queue trigger see that the maximum number of allowed jobs is still not 3 and trigger a third job again after the 30 minute check or will it not do so as no new transactions have been added?

2

The system checks periodically (I think every 15 minutes, maybe 30 by default) for items in the queue to kick off the trigger again. It should function exactly the same (if there is an item or items in the queue) as adding a new item would.

3

Ok, that’s what I was thinking but the documentation regarding new queue items is a bit vague. To confirm adding of new queue items kicks off the trigger to look for queue items in the new status and every 30 minutes the trigger looks for existing queue items in new status and sees them as new not existing items. This leads to faulted jobs getting restarted every 30 minutes.

4

By the way, if your Job is faulting, you need to address this in the code and do better error handling. Handle errors without faulting the Job.

5

Agreed. Except when its an environmental issue. Those we need address in the initialization block and fault the job. This specific issue is as follows and I would be open to any suggestions.

Initialization Block:
Open applications
Login to vendor portal attempts three times - say the login fails due to any reason
THEN

  • Job faults to ensure that the transactions in queue are not picked up to only be re-queued due to failure

I have been exploring the idea of adding this to the process block but then the transactions would only be re-queued and retried again (as our standard is to retry application exceptions 3 times to help overcome transient issues). Say our queue has 1000 transactions, this would mean we would not be notified of a true failure in this case until the transactions have retried three times (3000 transactions). So it makes sense to put this into the initialization block and fault the job to ensure our support can identify root cause and intervene / fix the environment / login etc. It is quite difficult to handle every possible system/application exception scenario and why we use UiPath’s native exception handling business vs system/application exceptions.

6

The Job still shouldn’t fault. You should catch that login error, notify, and end gracefully without processing any transactions.

7

Unfortunately your recommendation would leave this transaction in a successful or business exception state and makes it difficult to administer. Imagine you need to retry all the login failures, how would you recommend that be managed?