Retry Mechanism in RE-Framework

[anmolk171 (Anmol Kumar)]

Hi All,

I am working on RE-Framework and I need help in Retry mechanism in Queues.
Basically I am having bit of understanding of RE-framework but somehow I am missing something in Queues.
Lets say I have value 3 in Max# of Tries

So let’s suppose there is system error now it going to try again that queues so my question in REframework where it will update the value of Max# of tries and how retry mechanism work again and again until count is zero.
My assumption is after the system error it will create the transactions of that queues with decrease of one in number of tries.

Any help will be appreciated.

Thanks!
Anmol

[Raghavendraprasad (Raghavendraprasad Bhat)]

Well, REF will not store the value anywhere.

The transaction - Orchestrator will retry the item when REF is deployed again - without REF also it will retry, meaning, the retry of any queue item/transaction is independent of the REF.

If you have configured Max retries as 5 the transaction item in the queue with the status as failed will be automatically be retried when you deploy the bot again.

This is the short answer, but if you are unclear about how to retry every single activity or a whole workflow in ‘your code’ not from Orch. then you will have to look at options like Retry scope, Global handler or a custom loop in your code for retries.

Hope this answers it.

[ClaytonM]

Yeah, just as a simple answer… The Queue retry is a different mechanism as the REF. Essentially when a queue item changes to Failed status, Orchestrator will set it to Retried status and add the item again as New status, so your process can pick it up again.

The Retry mechanism in the REF will retry the item but not trigger the Retries in Orchestrator. So let’s say you retry an item 3 times in your code then it changes to Failed, then Orchestrator will set it as Retried, and when your process picks up the item again, it will peform retries 3 times again. It would basically do 9 retries (3 times 3), because you would have your Queue do 3 retries and the code would do 3 retries. I think many devs will have the code set to not do retries and let the Queue handle. On the other hand, I believe the localized retries along with the Queue retries is actually a good way to go about it, because some processes require many retries and will clutter up your queue. So, by setting your code to retry let’s say 5-10 times and have a lower retry for Queues, will allow it to handle those random application exceptions locally, and if it still fails, then attempt to process the item potentially on another machine or robot user.

Regards.