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.