Hi,
is there a time limit for processing 1 transaction in one orchestrator job?
Thx for answer.
Kind regard, Vanja
Hi, @VanjaV
Orchestrator has no fixed time limit for one transaction. To avoid errors, keep each transaction under 6 minutes. Long transactions might cause timeouts. You can add custom timeouts in your workflow if needed. This keeps processing smooth and stable
There is no time limit on within how much time a transaction should complete. Also there is no such good practice to have it under 6 minutes.
Itâs totally depend on your use case whatever time it may take.
Any particular scenario you are checking this for?
2 Likes
Hi @ashokkarale
I need to run job once a day. So in dispatcher I set up 1 transaction for job per day.
There are many lines to be processed within each day, the number varies. Yesterday the job stopped normally after 30 minutes. Well a bit later to finish the last line.
Now I am thinking of settinp up more dispatcher jobs per day to finish all the lines.
No, I can not make each line for transaction. Robot just performs one line after another. Whatever comes he processes.
Thx!
Kind regards, Vanja
This number comes from common advice to avoid robot session timeouts or workflow errors, but it is not a technical requirement.
The â6 minutesâ advice is not an official rule, but for reliable automations not a strict necessity
So, you can design your transaction duration based entirely on process needs. There is no official time-out limit from Orchestrator for transaction length
Ok @VanjaV
If you want to control the end time or the bot should be stopped in 30 minutes, you can enable scheduled end and kill time through the performer trigger like this. This will ensure the job is stopped/killed withing the timeframe.
1 Like
Hi @ashokkarale
the bot should not stop after 30 minutes. Actually, yesterday there were so many lines, it should work for some hours. But it stopped on its own. Now I am researching why 
.
But big thx for advice!
ahh ok @VanjaV. Got it.
Check the logs for possible reason. If it isnât configured to stop/kill it should run for the specified transactions.
Cheers!
1 Like
It means there was no transaction to process. This could happen only in two cases in REFramework.
- System Exception occurred in Get Transaction Data
- There wasnât really a transaction to process.
1 Like
Common advice from where? Chat GPT?
There is no such common advice.
Yes, there is no such official common advice
The suggestion about keeping transactions short is personal advice. ChatGPT was used only to help formatting
Its not âcommon adviceâ then and you have provided zero good reason for this time limit, which is why you are getting pushback from it. Its not helpful or relevant advice here.
If you want to explain a personal preference as this, do not frame it as âcommon practiceâ or a standard when its not, and qualify why you have this preference / what benefit it has and what you do when a transaction needs to take 15 minutes for example. Are you just refusing those automations? Or arbitrarily splitting the work. Without explaining your comments will just lead someone down the wrong path and perhaps make them think they need to do something they do not.
Thank you for the feedback. I understand there is no official transaction time limit enforce by UiPath.
My previous suggestion was personal experience-based advice to help avoid timeouts or issues. If a transaction takes longer its better to adjust workflow design, handle exceptions, or split tasks logically rather than impose strict time limits.
I appreciate the clarification and agree itâs important to tailor solutions to specific use cases without giving potentially misleading advice.
queue items get abondoned after 24 hours by default.. so longer items than 24 hours automatically are abondoned
apart from that you dont have any minimum limit as such
also if you have a dispatcher may be you might be giving the line number or so in the queue item..if so by adding more it can process more items..again this is on the intial speculation
cheers
3 Likes
Whilst correct the vast majority of the time, its worth pointing out the scenarios where a queue item wonât get abandoned. If the queue item was set into progress by a job that was suspended using long running workflows, as it waits for another queue item, job, action center form, agent etc, it wonât get abandoned after 24 hours and will stay in progress until the job finishes.
3 Likes
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.