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.
Can you please explain your debugging suite in terms of Orchestrator terminology? I would like to consider such an idea in my org.
I also second that it’s inefficient to constantly have this invoked workflow file to clean up any in progress queue items created while developing in studio.
I would also say the original post could have been written nicer. UiPath’s development and community engagement isn’t as bad as Microsoft’s, but this definitely a much requested ask as this product becomes more citizen-driven.
The idea with the
Debugging Suite is to have various useful workflows packed into a single process already linked to the same tennant/folder on Orchestrator. This way Debugging Suite will have access to the production assets and credentials. The Debugging Suite will only be for Debugging and not developing or editing workflows. This comes in handy when Production robot has exceptions and it makes fire fighting a little easier!
Depending on the process you are working with, you can decide what kind of debugging workflows would be necessary to minimize the downtime on a production robot.
Lets say you have a process which stores customer data in the queue item data and you use the Encrypted string of Customer Account Number as a reference.
An exception on a queue item will provide the Encrypted string of Customer Account Number
You can then use a workflow from the Debugging Suite lets say “DecryptCustomerAccountNumber.xaml” and find out the Customer Account Number for further debugging
A queue item is stuck at In Progress and you want to set it to new.
The workflow used in the thread, which converts such items to New
You need to quickly make an API request using the data from the Queue Item
You could have a workflow “DebugProductionAPi.xaml” which is already connected to your orchestrator and can get the required credentials and you as a debugger only need to be provide the required parameters. For example, the API call required Customer Account Number
So having a
Debugging Suite is a great way to be prepared for exceptions during Production.
And you are speaking of attitude? Interesting!
I am using an enterprise edition, which is $$$paid and I am still finding it frustrating to not being able to remove “InProgress” transactions, especially in the lower environments such as DEV or QA.