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.
Your queue setting is at orchestrator and if robot has a value for retry in your config file the robot will choose your config retry value. The closest value (file closer than orchestrator)
So the robot in your case will do 3 retries + 1 original try per item.
If you did not use config file setting then it would have done 4 retries + 1 original try per item.
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.
So, my query here is “the code would do 3 retries” means it is picking value from config or we as developer has handled to retry for 3times?
Moreover, my query was what if we have retry value in the config file also to retry.
I spoke too soon. There is an additional layer of logic which I skipped to mention, but the config file gets the last say on retires in REFramework and not the queue settings.
You can refer to the RetryCurrentTransaction in the REFramework and its inputs and outputs.
If you are using queues, you need not mention any value in config file, value specified in orchestrator will get picked. Even if both are specified, still queue value would be given preference when used.
This value in config is only required when there are no queues and in that retry is required for system exception.
I am also attaching Re-framework documentation file below, this will help you understand its working more in detail, you can go through this, would be helpful to gain deep understanding on re-framework working.
Lastly, When I tried after keeping the values both in config as well as orchestrator, just to understand which value the robot picks for retry in this given scenario.
So, yes the REFramework considered the value mentioned in the orchestrator instead of config.