Hi All,
While a job is running, a transaction is being abandoned midway, and a new job is getting triggered within the same process. I wasn’t able to identify any specific issue causing this behavior.
Could someone please help me look into this?
If a queue item is in progress or abandoned it should not trigger the process again, especially after only 4 minutes.
You can for sure get help, but you are going to need to share alot more information as we cannot see how you have written your code.
Perhaps start with how the process is being triggered?
Hi Smith,
During the job execution, I noticed that a new job is getting triggered while the previous transaction is still in In Progress state. As a result, the bot starts processing the next transaction from the beginning, even though the earlier one hasn’t completed.
From the logs, the observed wait time between the two executions is approximately 4 minutes, after which the new job gets triggered automatically.
It seems like the transaction is getting stuck mid-execution, causing Orchestrator to initiate a new job within the same process.
we used queue based triggers
Can you show your Queue Trigger please?
Lol mate, you need to show how its configured, not that it exists. Come on, help us help you out here, you need to be alot more proactive in giving valuable information to solve this.
Got it — thanks for pointing that out! I’ll share the configuration details so it’s clearer where the issue might be. I’ll post it here.
1 Like
Can you show your logs and are you using REF?
Trigger looks normal..is the next process getting triggered after few items? as per trigger after 5 more new items there would be one process triggered even if one bot is processing other items
And I hope you have multi login setup for your bot machines
cheers
1 Like
Hi Sai17,
This behavior most likely happens because a queue item is not being properly marked as Successful or Failed. If the transaction remains “In Progress” or encounters an unhandled error, Orchestrator may think it hasn’t finished and trigger a new job after the queue-based trigger interval.
A few things to check:
- Make sure every transaction is explicitly marked as Set Transaction Status (Successful or Failed) in your workflow.
- Review your process for any unhandled exceptions that might skip the queue status update.
- If you’re using REFramework, try debugging step-by-step through the Process Transaction state to see where items may not be completing correctly.
- The extra Jobs may be occurring just because of the rule to have a max of 5 pending jobs whenever you have 5 new items, so may be the 4 mins are just the time that was needed for 5 new items to get added.
In short, jobs retriggering like this almost always point to incomplete transaction handling or unhandled errors in the workflow. Fixing the queue status handling should prevent new jobs from starting prematurely.
1 Like
below are the logs:
yes, we are using reframework.
Yes, that’s correct — the next process is getting triggered after a few items, even when one bot is already processing. And yes, we do have the multi-login setup configured for the bot machines.
There’s no unhandled exception in the logs — but a new job is suddenly getting triggered while the previous one is still running.
can you please tell what are the next steps after get confidence scores log
also are these logs of single process? or single machine?
cheers
It will extract all the required values, log the confidence scores, and then add the queue item to the next process.
And yes, these logs are from a single process running on a single machine.
However, this scenario seems to occur randomly across different processes — there’s no specific pattern or single process where it consistently happens.
Thats a rough screenshot as its pretty blurry. But you set the trigger so that if more than 5 transactions are pending in the queue it will start another Job.
I suspect thats your issue, that you have more than 5 transactions in the queue so two jobs start. You’ve set it to run up to 5 jobs concurrently.
i suspect you have modified REF..
can you show some screenshots of try catch in process transaction, set transaction status, initilialize please..
did you hppen to modify anything in these?
cheers
Matey, the most likely solution is something is adding items to the Queue so its triggering the second process to start cause there are more than 5 items pending. His queue is literally set up to do this. The REFramework being modified would trigger more jobs, the Queue Trigger in this manner would.
Its most logical he doesn’t realize that more items are being added to the queue, reaching his threshold, and starting the second process, and maybe that happens about 4 minutes after the first process started cause the items are being added slowly.
1 Like
that was my first doubt as well and possible way
but he states the logs are from a single run and not single machine..so no second job issue issue..but in same job you have another start job log and fresh start
only way we can get a start job execution log again is if the job goes into if first run again which can happen only if aomething badly failed in ref and resetting something I believe..
cheers
Ah I see what you mean. Well if his process is triggering new jobs directly from his code, and not by a trigger, as he originally stated to me saying he uses queue based triggers then this is an incredibly poorly described problem and I suggest he start again fresh and make proper effort to give clear detail.
1 Like
can happen as well..but it should be invoke process and I dont think he would be doing that..as satrt process from same job also would trigger it separately
as it is REF mostly its the modification that should have caused it
cheers