Hi.
Hopefully, I can clarify some things for you, and this still gets me confused sometimes too.
I am working from an optimized REF where both localized retries and queue retries can be used simultaneously to perform a more efficient result. - in that case, yes, the total retries would be (retryNumber + transactionItem.RetryNo) as you pointed out.
However, if I remember right, the REF’s original retry mechanism was intended to use one or the other. So if you want localized retry, set your Queue to use no retries and set MaxRetry > 0. (You can still use the Queue for that reason). Now, keep in mind, that when you use the localized retry, this will attempt to retry on the same machine which it is currently running, therefore, if there is an issue with that machine, it will continue to fail… whereas, the queue retry will (potentially) choose a different machine to perform the transaction — i hope they improve it in the future where it prioritizes a different machine when the transaction fails.
The reason I wanted to use both localized retries and queue retries is just for that reason. I could efficiently make 5 retries, for example, on the same transaction on the same machine. However, if it still fails, I could have that transaction be attempted again on hopefully a different machine. I typically do 5 localized and 3 queue retries.
But, like I said, the REF is supposed to have you manually tell it if it is using the queue retry or not as it can’t tell automatically (from my understanding). Sure, you can look at the transactionItem.RetryNo, but RetryNo will be 0 on the first attempt and you can’t really tell it to use the localized retry when you have the queue use zero retries, etc.
So, essentially, it should use this logic:
- if MaxRetryNumber = 0, then increment transactionNumber, and use transactionItem.RetryNo in logging if desired
- Else, if retryNumber > MaxRetryNumber, then reset retryNumber and increment transactionNumber, else increment retryNumber
So, retryNumber is really only incremented when MaxRetryNumber is used, otherwise, it uses the queue’s RetryNo. However, as I mentioned, it will ignore the retryNumber if the queue is used. Bear in mind, that the retry transition in the state machine should also be ignored when the queue retry is used.
TransactionNumber represents the transaction for the job run on each particular machine. The reason this gets incremented when using the queue’s retry is because each queue retry is a different transaction since it can be performed on different robots/machines. Localized retries will not increment this because the transaction is still being performed on the same machine with the same job run. - hopefully, that makes sense.
If you choose to use both localized and queue retries, then you can make some adjustments where you log two different numbers: retryNumber and transactionItem.RetryNo, one being for localized retry and one for queue retry.
![image](https://global.discourse-cdn.com/uipath/original/3X/b/d/bd70878e63c581b4093681c6e0c66df713771f34.png)
The logic is mostly similar to the REF’s but some slight changes. Although, I chose to use a Switch to go between “Successful”, “No Retries”, “RetryAttempt”, “MaxRetries”.
Let me know if you would like to clarify further on anything, cause I put a lot of words on this reply ![:upside_down_face: :upside_down_face:](https://emoji.discourse-cdn.com/twitter/upside_down_face.png?v=12)