Disallow retry of transaction

orchestrator
queue
i_considering
retry

#1

Hi,

It could be beneficial to have a possibility for the robot to mark current transaction as not retryable.
This could be done with separate activity or as part of updating transaction progress.

Use case:
We have projects where a single transaction has 2 or more “closing” steps. Currently we cannot set that queue with retries, as failures after 1st “closing” step need to be handled by human.
If we’d be able to mark a transction as not-retryable, we could normally use queue-based retries with them without worrying about having double entries on 1st “closing” step.

Simplfied sample scenario:
Queue consists of a list of tickets to process. Processing consists of doing an action specified in the ticket and closing the ticket.
Action X is performed succesfully, but ticketing system cannot be reached/ticket can’t be closed due to error in ticketing system/robot crashes/w-e. This should fail with Application error.
Transaction cannot be retried, as the action would be performed second time.

For a second transaction there’s an app error during performing the action. Action could be retried, but the queue cannot be set to allow this.

It could be argued that these transaction types are not atomic and hence should be split up, but it’s not always feasible to do that. Having an option to mark a transaction as not retryable would easily fill the gap and shouldn’t have high footprint in Orchestrator/DB load.

In addition, a property/method could be added to QueueItem, that would return a bool IsLastAttempt (if retryNo = allowedRetries). That way process could be developed in a way to report last attempt fails differently (f.e. to final report instead of partial), without hardcoding any values in the workflow itself.