A queue is having ‘Unique Reference’ enabled.
So, if a queue item was added on April 1st, 2022.
The same queue item was processed successfully on the same day.
History of changes in queue retention settings:
‘Delete’ after ‘180’ days on July 7th, 2022
‘Delete’ after ‘90’ days on August 1st, 2022
‘Delete’ after ‘30’ days on August 2nd, 2022
Could you please tell me which of the above setting was applied to the queue item that is added on April 1st, 2022.
For example, if we say – the last setting was applied to the queue item, that is: ‘Delete’ after ‘30’ days on August 2nd, 2022.
Does this imply that the queue item will be deleted by August 29, 2022?
(30 + 120 = 150 days, starting from April 1st, 2022)
Could you please help us to calculate as to when that same queue item can be re-added into the queue.
Or calculate the total retention period for this case.
We would like to be able to re-add the same queue item into the queue without getting error: Duplicate reference.
Please note that the same queue item is ‘NOT’ seen in the transaction lists.
So, it might have got deleted by the retention policy. And we have no archives.
Even with help of Export option from Queue page, we are not able to check for the same queue item that was added on April 1st, 2022.
When does this archiving process run? Is it daily at a set time? For example, every day at 3am the system looks for queue items that should be archived and moves them to the Storage Bucket?
Also, your naming convention for the archive Zip files is terrible.
Just use the queue name instead of the queue key. This way we could have just one Storage Bucket for queue item archiving and then it would be easy to see which Zip file is for which queue. The way you’re naming these files, we are going to have to create a Storage Bucket for every queue so we know what is what.
And due to our industry, regulations, and compliance, deleting data is ILLEGAL. This means we are now going to have to go through our existing hundreds of queues and reconfigure them because you’ve set a default of DELETE. Very bad design. This is another prime example of UiPath apparently not having people who understand how enterprises function, and making decisions that severely negatively impact us.
And for reasons already stated, forcing us to archive or delete is not good. Others have already given you exact scenarios where it causes problems - and it has been over 3 years and you haven’t taken into account this feedback.