Difference b/w Retry in Config File and Retry in Queue in Orchestrator

Hi ,
May I know the differene between Retry in Orchestrator queue and Retry in Config File.
Thank u.

The main difference is where you’re configuring the number of retries. Obvious as it sounds, setting the Config file to retry in Orchestrator means you manage retries in Orchestrator, whereas if you set the retry count in the Config file to something greater than 0, you’ll manage it in the Config file.

Really it depends on how you want to manage the retries. I’ve found it easier to manage retries of transaction items through Orchestrator, whereas I use the Config file for processes which cannot use an Orchestrator queue to run. You can simulate the behavior of the Orchestrator retry functionality in the Config file, however, if you save the Config file to a network drive and make modifications thorough that copy.

3 Likes

In simple terms,

Retry in Orchestrator - When you use orchestrator queues in your workflow.
Retry in Config - When you do not use orchestrator queues in your workflow.

Regards,
Karthik Byggari

2 Likes

Thank u.

Thank u Karthik.

1 Like

Hi Karthik ,

Then what would be the case if we have both , so which is priority here , either orchestrator queue retry or config retry.

Priority is Queues. To support multi-bot architecture it is recommended to use Queues. And also queues provides the stability of the bot, average processing time of each transaction item, completion time, you can re-add failed queue items and many more.

If you use an Orchestrator Queue, and you set the “# of retries” there when you create Queue, then when REFramework (or your own developed workflow) you will try to process a transaction and if you fail you will notify your queue by
using the Set_TransactionStatus activity set to “Failed” (with System Exception type),

Then it will actually only set it “Failed” if the # retries were actually reached for that particular transaction item (at this point it is handled by Orchestrator), if the #’ is not reached, then it will set the queueitem automatically to “Retried” and it will create a “New” (exact copy of it) as well, so the set_transactionstatus will set it ‘retried’ and at the same time and re-adds it to the queue (I believe to the first place).

If you use the other method, no Orchestrator queue, (for example you use DataRow as transactionItem, and you get your data from a DataTable), then REFramwork will handle retries based on the MaxRetryNumber coming from the Config file, it won’t create a “new” queue item or a “retried” queue item (how could it? when there is no queue), it will simply retry by “not incrementing” the index of your DataTable/array/List or whatever you used for your data source. so when you prepare your “GetTransacionItem.xaml”, you can still rreference your item like mydatatable(transactionNumber) because it will use the same transaction number in the retry… something like that.

And again, otherwise, if Orchestrator was used to handle it, it will be a new transaction number (the previous one+1), but you will have a “New” queue item too (and a retried).

When you configure both the retry mechanism in the config file and the retry mechanism in UiPath Orchestrator with values greater than zero, it means you have redundant retry settings for handling errors and retries in your automation process. In such a scenario, the retry logic can behave differently depending on where the failure occurs.

  1. Retry in Config File:
  • The retry mechanism defined in the config file applies to the specific activities or operations in your automation workflow that you have set up for custom retry handling.
  • When an activity fails within the scope of the custom retry logic, the workflow will use the retry settings from the config file to determine if and how many times to retry the activity.
  1. Retry in UiPath Orchestrator:
  • The retry mechanism in Orchestrator applies to Queue-based transactions managed by UiPath Orchestrator.
  • When a transaction item fails during processing, Orchestrator will automatically apply the retry settings configured for the Queue to which the item belongs.
  • The retry settings in Orchestrator Queue will determine how many times the transaction item will be retried if it fails.

Here’s what may happen when both retry mechanisms are in place:

  • If an activity fails, and the failure is not related to a transaction in the Orchestrator Queue, the custom retry logic defined in the config file will be used for retries.
  • If an activity fails, and the failure is related to a transaction in the Orchestrator Queue, both the custom retry logic defined in the config file and the retry settings configured for the Queue in Orchestrator will be considered.
    • Depending on the implementation, the retry settings from the Orchestrator Queue may take precedence over the retry settings in the config file.
    • The number of retries for the transaction item may be determined by either the config file or the Orchestrator Queue settings, whichever is higher.
    • The same applies to the retry interval, where the longer interval from either source may be used.

It’s essential to avoid redundancy in retry settings to prevent unexpected behavior and ensure that the retry logic is applied consistently and as intended. In general, it’s recommended to choose one central location for retry logic (either in the config file or in Orchestrator Queue settings) based on your process design and requirements, rather than having both in place.

Hi @saritha

  1. Retry in Orchestrator queue:
    When you set up a queue in UiPath Orchestrator, you have the option to configure the number of retries for each transaction in the queue. If a transaction fails during processing, Orchestrator will automatically retry it according to the specified retry settings. This allows you to control the retry behavior centrally from Orchestrator.

  2. Retry in Config File:
    Retry in the config file is a custom retry mechanism that you can implement within your UiPath workflow. Instead of relying on Orchestrator queue settings, you manually define the retry logic and the number of retries in the configuration file of your workflow. This gives you more control over the retry process at the workflow level.

Both approaches have their advantages and use cases. The “Retry in Orchestrator queue” provides a centralized and easy-to-manage way of handling retries, while “Retry in Config File” allows for more flexibility and customizability in defining the retry logic. You can choose the one that suits your automation requirements and preferences.

Hop you understand!!
Regards,