Job execution restarts mid way through a job

Scenario: While running a job it silently restarts mid-way through the job execution. The log shows a new “(Process name) execution started” entry on page 11 and the transaction item is left in a “In progress” state.

Steps to reproduce: Unable to reproduce the issue, but it happens occasionally.

Current and expected behavior: The job should preferably not restart or at least fail with an error message.

Studio/Robot/Orchestrator Version:

This issue has occurred on different Studio versions
Studio: 2018.3.3
Robot: 2018.3.3
Orchestrator: 2018.3.1

OS Version: Windows 7

Others if Relevant: (workflow, logs, .net version, service pack, etc):

See screenshot for reference.

Hi @krbg00

maybe @loginerror can help you out with this one because we don’t have any details about the process and it is not possible to reproduce it, also it doesn’t seem to be a problem of development rather than a bug in an activity or something like this.

Thanks for the reply. Then maybe if @loginerror can tell me what he needs I will try my best to deliver any logs or anything else I can.

Hi @krbg00

I would definitely suggesting contacting technical support with this one.

Does the process have any retry mechanism that can swallow the exception (In the form of Try-Catch routines)? If I understand correctly, by the “execution restarts mid way” you mean that it continues to work properly after that?

Hi @loginerror

The whole process is inside a Try Catch but I rethrow in the catch section so the exception should at least be logged.

By “execution restarts mid way” I mean that the job halts (but does not stop or fail) and starts again from the beginning in the middle of the previous job execution. There are no new jobs started on the Jobs page in Orchestrator. In the screenshot you can see the initial log message of the job in the middle of the already running job. It continues to run properly after that yes, but the transaction item it was working on is stuck in a “In progress” state and because of the way I add cases to the queue there is a risk that the case could be worked twice depending on how far it got into the transaction before the job restarted.

For what you are saying, it really seems like there is an overarching try-catch that swallows the exception in the end. All symptoms for that are there:

  • project doesn’t throw an exception
  • project restarts from the beginning (this suggests that the Try-Catch would be encapsulating the entire project)
  • project works normally and fetches the new item, while leaving the previous one InProgress (this makes sense, because it never got to change the status of that previous item)

Thus, either something wrong with the exception handling or a very weird bug indeed. If you are absolutely certain of your workflow, please contact our support or share bits of your workflow here for us to investigate (can even be a private message).

We definitely want to catch a potential bug like that :slight_smile:

I am still experiencing this error. Previously, it was only one process this happened to, but now I am seeing it happen in multiple processes. While it happens rarely it still causes issues.

This is not a problem with “overarching try-catches” because it seems like the job execution restarts in the middle of an already running job. It forgets all about the transaction it was working on, leaving it in the “In Progress” state. I also see that after the second “(Process name) execution started” entry there are log entries which only show up at the very beginning of the process (like logging screen resolution, etc).

I have a log activity in all the catches which do not show up, so it is not a problem with the Try Catches.

This is a critical bug because there is no way to detect or handle the restart and it could result in unexpected behavior.

This still happens after we updated to Robot 2019.4.3 and Orchestrator 2019.4.2.

This is from the same job:

More evidence of the restart:

I will need to suggest contacting our technical support again. It can be something very specific they are aware of.

If it is indeed a bug, they will also be able escalate it to our product team.

1 Like