It’s ridiculous that we can’t delete them without deleting the entire Queue. There is no reason whatsoever we should be prevented from deleting any Queue Item we want. People have been asking about this on the forums for years, and still no solution.
that attitude cant take you very far, still must be something of how the database and tables relationships were designed so changes would affect a lot of upgrading customers… Still why would this be so important to see them removed instead of having Deleted status?
It would help if you understood the question. The issue is that you still, for some ridiculous reason, can’t remove an In Progress queue item; you have to wait 24 hours for it to be abandoned. The issue is not that they want the rows to no longer be visible in the queue.
Hi welcome to the community!
And i think i have answered the reason why it cant be deleted… Still i dont see what is the reason that this causes so much trouble to some people…
I just like to keep things tidy, and it’s a hassle not to be able to do such a simple thing. It’s not really a good answer that there are related tables, that is easily managed. It’s no different than deleting an abandoned queue item, as far as other records in other tables. It just perplexes me when companies do things like this in their design. They make things restrictive instead of allowing their users to decide how to do things. Like not being able to designate a specific robot for a queue trigger. Makes no sense.
If you are a paying customer, you do have every right to ask for the product to be improved, it is just not the best way to do it… We have a category meant just for this:
From February 2017…and still not addressed…
By the way, deleting and recreating the queue isn’t a good option as it would (I assume) result in the Queue ID changing, which would break external code that’s using the ID in API calls.
You should never have to delete and recreate something to edit its properties, remove records, etc.
well it was addressed, delete was implemented, you just dont like the way it was done… anyway only 2 votes from that, means no one was very interested on it…
actually I am quite interested in it. Any queue that is set up with Unique reference, cannot have the same queue item uploaded until and unless that “In Progress” item has been dealt with. There is no way in orchestrator to deal with it apart from deleting and recreating the queue.
Dear UI Team,
I echo the same. There should be some way to delete the In Progress queue item.
I agree on this.
Please let us manually delete an in progress queue item. It is not good practice that you should delete the whole queue to get rid of one item. You loose all history of transactions which are often used for statistics.
Is it easier to implement a solution where you can flag an “in progress” item as failed/abandoned?
@bcorrea I think this thread adds to the two votes you are referring to.
Dont forget that i am not against you in any way, i am an UiPath user just like you, the work i do here is voluntary… But i just dont see that enormous need to actually remove an item from the queue, just because it failed… Even when you talk about statistics, remove an item from the queue also messes up the statistics…
We (@otico and I) are recent converts from BluePrism. In BP an in progress queue item can easily be first stopped / aborted and then it can be deleted by the user. The database / queue will retain these queue items. This saved us a lot of time when debugging both during development and production.
We looked at this thread and we want to help with a workaround. Our approach is -
Get Queue Items: Get all your queue items with status “InProgress” - Inumerable output
For each QueueItem (Inumerable)-
Set Transaction Statusto “Failed” with a given
Reasonin properties tab
Get Queue Items: Get all your queue items with status “Failed” - Inumerable output
For each QueueItem (Inumerable)-
Delete Queue Item
We tested it on Orchestrator On-Prem v20.04 and it works . The deleted queue items still showup in the Orchestrator Queue, which is exactly how it should be. It is always best to have this traceability. We did not have to delete the queue.
Here is the solution file: DeleteInProgressQueueItems.xaml (8.2 KB)
This is a workaround using official queue activities, that said, please ensure that you do not run this flow when one of your robots is running a dispatcher / performer process linked to the same queue. Also, if you use this approach at the end of REFramework (to keep the queue clean), ensure you have necessary routines to identify which items need to be sent to the queue next time the dispatcher runs.
If you want to get the ItemData for the deleted items and add them to the queue as a new Queue Item, this is possible too. All you have to do is parse the inumerable resulting from Step 1 or Step 3 and get the data associated with the failed/deleted item and pass it to the
Add to Queue activity accordingly.
Hope this helps!
I second @postwick on the notion that “In Progress” queue items should have an option to be “Removed” just like Successful and Failed queue items.
I find it frustrating to have to delete my entire queue multiple times because my queue item with unique item reference can’t be recreated, due to the hold on an existing in progress queue item. @UiPath please consider enabling the “Remove” menu option for “In Progress” items.
I don’t want the item to be taken from the queue after removal, just move it to a “Deleted” state.
Even had the misfortune of having to explain this to the client because I couldn’t simply delete the in progress items. They queried me why there are “in progress” items on the queue, while my process isn’t even running (at the time) following an process exception which couldn’t set the items to Failed.
I can confirm, that @jeevith’s way is a good way to handle items with status ‘in progress’. I must confess, that it would be easier if there would be a way in Orchestrator to change status or delete them, but if it is not possible, I did it another way:
I used some similar steps, I just wanted a way to “restart” them, when they are in progress and the bot failed somehow. So I
- Get Queue Items with filter ‘in progress’
- For each item I set the status to ‘new’
- Get transaction item and run the bot again
I use the same process but it still is a pain that it’s not built-in Orchestrator. Every time I run tests, I have to run my workflow to delete/reset all in progress transactions which is a pain when I could simply open Orchestrator select all in-progress transactions and click a delete button or similar.
We are glad it was of help to you.
We feel your pain. Out approach currently is to use the suggested workflow as one of the functions in our
Debugging Suite. A debugging suite makes it easier for us to maintain robots in production.
Other functions in the
Debugging Suite can be use are Encrypt / Decrypt, adding dummy data to test versions of application, testing API etc.