ReFramework - Retry queue items

Hi guys.

I’m using the Re-Framework to develop a process and I’m facing a problem with the retry queue items.
I’m forcing a System Exception while processing an item. Then, it closes the application, starts the applications and starts to work again on the item that stopped. After the whole list is processed (including the item that failed), it goes back to this item and tries to process it again.

As you can see in the below image, it should be good after the status is successful and it shouldn’t create a new queue item as I think it does.

Can anyone help me with this?

Thank you!


You are correct!. ideally it should not add an entry. but to add more light to this situation, we need more info. screen shot at different processing stage. Failed, successful , and item recreated.

current screen shot does not convey the process flow or the situation u want to explain

While creating the queue itself it will ask for the either duplicates allowed or not right ?
Are you allowing duplicates of its not successful?

Didn’t got the question properly

Hi @megharajky and @FebinKAndrews

I think that my problem is related with the “MaxRetryNumber” of config file that is > 0 and I also have “Auto-Retry” on the queue configuration a True.

Let me do more tests and I’ll say something.

When we are creating a queue, it will ask about the “Unique Reference” and “Auto-Retry” only. And the Unique Reference doesn’t consider the queue items that retry.

Retry attempt on queue always overwrite the MaxRetryNumbe of config file. also it is suggested to keep MaxRetryNumber =0 if you are using queues.

Hi @FebinKAndrews

For example, I add 5 items to a queue.
When a error occurs, I need help to understand why the same item is processed 3 times instead twice:

  • one at the first time when the error appear; (CORRECT)
  • one when is retrying to process it again and done it successfully; (CORRECT)
  • one at the end of the 5 items were processed. It tries to process one item already processed. (???)

Which parts of the workflow do you want to see?


at second point, after it processed, can u please check whether the status of that item is updated to ‘Sucess’ from ‘Failed’ . If the status is not updated, it will retry again [ based on no of re-try attempt ]

Also try with retry attempt limit to 1 in orchastrator and 0 in config file and check please

As you can see on the above image, (where is the arrow), the status changes to Successfully.
And I was trying with limit to 1 in Orch and 0 in config file.

Note: I turned off the “Auto-retry” when creating the queue and when the processing of an item crashes, it closes everything and starts again, and process the item that failed. Don’t understanding the “auto-retry”… I’ll search about it


Hey guys, so just to be clear here, is Orchestrator is actually retrying successful transactions? if so is it actually retrying the successful transaction in orchestrator, or has it seemingly created a duplicate which it has tried instead (you mentioned duplicates above)?

NB - for the purposes of your testing, keep all the auto retry functions turned off, so that you can see exactly when it is displaying unknown behavior

Auto-retry function of Orchestrator queue only works with items that has System Error. If the item encounters a BusinessRuleException, then auto-retry will not function. So if you want your transaction item to stop in your specific scenario while having an auto-retry, you could throw a BusinessRuleException.

Closing of the applications and restarting back to InitAllApplications is a normal behavior when using ReFramework if you encounter a System Error.

Going to the Handle System Error sequence under SetTransactionStatus workflow, you could see below that it has an invoked CloseAllApplication workflow.