Orchestrator queue processing jobs past deadline

orchestrator

#1

I useUiPath.Core.Activities.AddQueueItem and UiPath.Core.Activities.GetQueueItem to populate a queue of jobs in Orchestrator. I add a deadline (today at 04:00:00 AM). However UIPath can still get and initiate processing of the tasks after the deadline. Do I manually need to check if the deadline has been passed?
I expected UiPath.Core.Activities.GetQueueItem to skip tasks when the deadline was passed, and leave the status as “New”.


Past and future jobs are treated equally.


#2

Have the same question.
@Tiramisu did you ever find an answer for this?


#3

I am manually checking each job now since i didn’t find any build-in solution.


#4

ok
I’m considering using ether that, or try some solution with queueitem.retryNo, or a combination of the two.

thank you for the answer :slight_smile:


#5

Hi guys,

This is the intended behavior because the Deadline property is, as specified in the user guide, a criterion for the prioritization of queue items, alongside Priority and Postpone.(https://activities.uipath.com/docs/add-queue-item)

This means that if you have two High priority queue items and only one of them has deadline, this will get processed first(even if the deadline has passed). In other words, if you set a Deadline, it doesn’t mean the processing will skip that item, but it will prioritize it.

Same thing with Postpone: if you set a date/time the item will not be processed until that date/time(because you’ve set it a very low priority) but it will eventually be processed.


#6

Hey @ovi

Thank you for the clarification

However i feel i must challenge you on this.
Deadline and postpone does NOT have the same behaviour.
Postpone gives a bottom limit that ensures the queue item WILL NOT be processed before the date sat.
If you translate this behaviour to deadline, it would mean that deadline should set an upper limit that ensures the queue item WOULD NOT be processed if date was reached.

I also feel that the name “Deadline” is misguiding for the same reason. As you can read from above posts, when i hear the word Deadline, i would assume that the item is “dead” (abandoned) after reaching the “deadline”.
a wording like "Prioritize if after " would be much easier to understand. Even your old wording “Due date” would be better i think.

As you say, UiPath have the behaviour documented, so it clearly is working as intended.
Would you consider implementing an “abandon date” for queue items?

The usecase i have right now:
I have a robot that runs once a day that processes queue items.
If the processes fail with business exception, i want to try again tomorrow.
If it fails tomorrow i want to abandon it from the queue.
If it fails with application exception, it will auto-retry.
If the auto-retry fails, i want to abandon it from the queue.

This means i cannot use queueitem.retryNo, as if it fails once with application exception and then on the auto re-try fails with application exception, retryNo will be 2 where it should be 1 application and 1 business.

I also found no way of getting the creation date of a queue item, so i can’t make my own logic, unless i “manually” stamp queueitems with date when they are crated

To sum up:
It’s not impossible to workaround this, but since UiPath already made our life easier with postpone, “deadline” and priority, why not also make one for abandon date?


#7

This might be a good idea. Is it really needed or it is an isolated use case? I tend to think that it is not needed. Like you said abandon date can be manually “stamped” within the Specific Data of an item. However, Due Date and Postpone can not as we need to have indexes on those specific SQL columns.


#8

Is it possible to add our own SQL columns? Then we can extend the functionality as needed. As it stands, I need to run a separate SQL server.


#9

No. Create a new database and keep it there. How will we handle migrations if you alter the db structure?


#10

I could see other projects needing this as well. When handling time sensitive data, or when dealing with a system that only take 1 entry per day (but maybe retryNo would be enough here.

To be honest, i don’t really know.
My guess is that i will use it in other projects as well, but i don’t know until i see them :slight_smile: