Disallow retry of transaction

Feedback Activities
, ,
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.

2 Likes
2

I have this exact issue, the bot creates a claim and then adds attachments. The attachments can’t be added to the claim during creation, only after. If an application error fails before a claim is created in the system, the bot can retry, if the claim is created in the system we don’t want duplicates and the transaction should not be retried, and the attachments would need to be added manually if the failure occurred before the attachments where done

3

UPDATE - Set Transaction Status to a BUSINESS exception does not trigger a transaction retry.

Hello,
Does anyone know if this has been implemented? I want to clear down my transactions if the application exception is Fatal (vs non-fatal, where the transactions can be retried). I’m Setting Transactions Status to failed but because the queue is set to retry once, all of the transactions I need to delete will be retried by the current logic.

4

You can work this around. Just after the failed status is set you can query the queue for new transactions with the same reference number as the current item (Get Queue Items) and delete them. Not the most elegant solution but it works in my case.