UiPath Pitfall #3: Expecting Orchestrator to Retry a Business Exception

Описание и применение

В UiPath ReFramework неверная классификация исключений приводит к неверному поведению повторных попыток в очереди. Разделяя BusinessRuleException и ApplicationException, можно управлять повторными попытками и улучшить прозрачность ошибок.

Задача

Queue items fail without retry or are retried unnecessarily due to incorrect exception classification in UiPath Orchestrator.

Результат

By distinguishing BusinessRuleException from other exceptions, queue items are retried only when a technical issue may resolve, preventing wasted runtime and improving failure transparency.

Рабочий процесс

• 1. In Process.xaml, validate input data early and throw BusinessRuleException for data issues.
• 2. In SetTransactionStatus.xaml, set ErrorType to Business for BusinessRuleException, Application for others.
• 3. Configure Orchestrator queue with Auto Retry enabled and set MaxRetryNumber to 0 in REFramework config.
• 4. Use Retry Scope for flaky steps that need immediate retry without failing the whole item.
• 5. Handle shared login failures in Init state and stop the job if necessary.

Доказательства

Application exception + Auto Retry turned on for the queue: Orchestrator retries the item, up to the queue's max number of retries.

Источник

Business exception: Orchestrator doesn't retry it by default.

Источник

In REFramework, what you throw is the decision.

Источник

Ask one question before throwing: would running this exact item again, unchanged, have a real chance of working? Yes means Application. No means BusinessRuleException.

Источник