I am looking for specific documentation that tells which statuses of queue items should be returned by calls to “Get Transaction Item”?
I have a “queue consumer” workflow that starts from a queue trigger of “new transactions” in the queue. It uses Get Transaction Item in a loop to process until there are no more “new” items. The workflow is designed to be scalable in that multiple copies of the workflow can run concurrently (depending on how many items there are in the queue). Get Transaction Item is nice because it allows the concurrent processes to grab unique items and “start” their “transaction” without worrying about two processes grabbing the same item.
This all works fine as long as no items “fail”. In this application, a user reviews and performs a different, manual process on the “Failed” items. The problem I’m having is that after some random amount of time, the “Failed” items are again retrieved by Get Transaction Item the next time there are other actual “New” items. I’ve tried manually removing the Failed items and they will show in the queue with a status of “Removed” but those transactions eventually appear to get internally recycled and also get retrieved with “New” items the next time there are actual “New” items in the queue.
My queue is NOT set for Auto Retry (it was originally setup with retry, but that check box was unchecked later), so I’m wondering why Failed and Removed transactions are getting retrieved by Get Transaction Item. Would recreating a fresh queue help (since auto retry was at one time enabled)?
Get Transaction only gets a New queue item. When it gets it, it sets it to In Progress.
The problem I’m having is that after some random amount of time, the “Failed” items are again retrieved by Get Transaction Item the next time there are other actual “New” items.
Get Transaction cannot get anything other than New queue items.
Would recreating a fresh queue help (since auto retry was at one time enabled)?
You should definitely try this. You may have identified a bug where the retry doesn’t actually turn off if you change the setting for the queue.
Are you using REFramework? It has retry functionality built in that is set up in the config file instead of on the queue itself. This could be why failed transactions are being recreated as New.
There might be issue with removing the auto retry …
Having retry in config will rerun the failed ones …but it would happen immediately and also a new item is not added…It cannot add new itesm if retry is set from config
The only possible case might be even after turning off auto retry in queue it is still in effect
@postwick , Thanks for the reply. To clarify, the failed/removed transactions are showing up with statuses of “Removed” or “Failed” when they get “started” by Get Transaction Item (not showing as “New”).
This is a non-REFramework workflow and the queue was setup manually and then changed to turn off auto retry because we realized we didn’t want it.
I will try re-creating the queue. I agree it sounds like a bug with auto retry not turning off when de-selected. I have a support case in with UiPath but it is taking a long time on their end and they haven’t yet suggested a bug.
When auto-retry is functioning, the original queue item gets set to Retried and a New queue item is then created with the same data as the original queue item. You could test this by creating a new automation that simply does a Get Transaction then Set Transaction Status (to failed/application). Then look in the queue and see what’s there.
@postwick ,
I agree with your simple explanation of how the queue processing is supposed to work. I did go ahead and set up a test that sets transaction status on items in a brand new queue that I set up. All worked as expected, so I’m going to conclude that the prod queue that I have a problem with is corrupt some how and have now created a replacement for it.
The really crazy thing that I discovered as I looked into it is that in my real application on that prod queue, the exception type is being set to “Business”–so no retry should ever happen, but yet that was what was happening. When I tested on the simple test mentioned above, Business exceptions were never retried, and Application ones were retried if the queue was set up for retry.
So hopefully, this is just a one off and getting rid of that corrupt queue solves the problem.
Thanks for taking the time to offer insight on my question!
