3.2 Retry Mechanisms: Queue Retries vs. REFramework MaxRetryNumber

3.2 Retry Mechanisms: Queue Retries vs. REFramework MaxRetryNumber

Core Concept: REFramework can retry a failed transaction in two places. Orchestrator Queue Auto Retry is configured on the queue and creates a new copy of an item that failed with an application (system) exception. Robot retry, controlled by MaxRetryNumber on the Constants sheet of Config.xlsx, re-processes the same record inside the running job and is meant for data that does not come from a queue. Knowing which one applies, and what the template actually does with each, is a favorite exam topic.

Transient failures are normal in production: a web portal times out, a Citrix session lags, a database is briefly locked. A retry gives the transaction a second chance after the robot has reset its applications. The question is who owns that retry.

---

Mechanism 1: Orchestrator Queue Auto Retry

When you create or edit a queue in Orchestrator, the Auto Retry section controls retries. In current Automation Cloud Orchestrator it has two checkboxes:

• Failed items — retries items that fail with an application exception.
• Abandoned items — also retries items that were abandoned. When this is selected, the Max # of retries field appears, and it accepts a value from 1 to 50.

When the performer sets an item to Failed with ErrorType = Application and retries remain, Orchestrator does the following:

1. The original item's status becomes Retried (not Failed), which records that a new attempt was created.
2. Orchestrator adds a new item with status New that carries the same SpecificContent and Reference, and its RetryNo is one higher than the original's.
3. Any robot that calls Get Transaction Item can pick up the copy, according to the normal priority and deadline ordering.
4. When the last allowed attempt also fails, that final item keeps the status Failed.

Two outcomes need special attention:

• Business exceptions. An item set to Failed with ErrorType = Business is never retried automatically, whatever the queue settings are, because the data itself is wrong.
• Abandoned items. An item left In Progress for about 24 hours becomes Abandoned. It is retried automatically only if the queue's Abandoned items option is on. Otherwise a reviewer can set the revision status Retried in Orchestrator, which adds a new copy. Manual retries do not count toward Max # of retries.

Changing Max # of retries affects only transactions that fail after the change; items that already failed are not retried retroactively.

---

Mechanism 2: Robot Retry with MaxRetryNumber

MaxRetryNumber is a row on the Constants sheet. Its description in the template reads, in effect, must be 0 if working with Orchestrator queues; if greater than 0, the robot retries the same transaction that failed with a system exception.

The logic sits in SetTransactionStatus.xaml (in recent template versions it is split into Framework\RetryCurrentTransaction.xaml). After a System Exception it decides between these branches:

' Simplified robot-retry decision for non-queue data (System Exception branch)
If io_RetryNumber < CInt(in_Config("MaxRetryNumber")) Then
    io_RetryNumber = io_RetryNumber + 1          ' retry the same record
Else
    io_RetryNumber = 0
    io_TransactionNumber = io_TransactionNumber + 1 ' give up and move on
End If

Why the template says "must be 0" for queues

Because the template checks whether the transaction item is a QueueItem, a positive MaxRetryNumber does not make it re-run a queue item on the same robot. It only changes the log text, which is then driven by the queue item's RetryNo. The number of attempts is still decided by the queue's Max # of retries. Keeping MaxRetryNumber at 0 for queue-based performers keeps the logs honest and leaves one clear owner of the retry policy.

The real danger is a customized framework. If a team rewrites the retry logic so that queue items are also retried locally, each Orchestrator copy gets its own local retries. The attempts then multiply: with 2 local retries and 2 queue retries, one broken item can run (1 + 2) × (1 + 2) = 9 times. Design reviews should reject that combination.

---

Walkthrough: Queue Auto Retry = 2, MaxRetryNumber = 0

Between cycles the robot goes back through Initialization. io_TransactionNumber increases after each failure, because the framework always asks the queue for the next available item. The queue decides whether that is a retry copy or a different invoice.

Walkthrough: Excel rows, MaxRetryNumber = 2

Row 3 throws a System Exception. io_RetryNumber becomes 1 while io_TransactionNumber stays 3, so after re-initializing the applications, Get Transaction Data returns row 3 again. If row 3 fails twice more, the counter reaches the limit, resets to 0, and the framework moves to row 4.

---

Why the Retry Path Goes Through Initialization

After a System Exception, SetTransactionStatus.xaml takes a screenshot and tries CloseAllApplications.xaml, falling back to KillAllProcesses.xaml. The System Exception transition then returns to Initialization, where InitAllApplications.xaml opens fresh sessions and logs in again. The Config dictionary is already in memory, so InitAllSettings.xaml is skipped: its call sits inside an If Config Is Nothing first-run branch. The retry therefore runs against a clean application state instead of a frozen window or a half-submitted form.