Previous state persists when running consecutively on the same robot

Japan Forum
, ,
1
  • Robots: UIP01 and UIP02 (one is selected at random)
  • Execution trigger: Call the Orchestrator API from Power Automate
  • Execution mode: Unattended
  • Job status in Orchestrator: Both show “Successful”

When the same workflow is run twice in a row, it behaves as follows:

  • Case 1: First run on UIP01 → second run on UIP02 → works as expected
  • Case 2: First run on UIP01 → second run on UIP01 (or UIP02 → UIP02) →
    Runs with the previous execution state still in place

In other words, only when the same robot is used for consecutive runs,
the cache and application state are not reset, and the robot behaves as it did during the previous run.
Since Orchestrator shows “Successful,” the job did not terminate abnormally.

Is there a way to completely disconnect the previous session before running again on the same robot?

If anyone has experienced the same issue or knows how to check the settings,
I’d appreciate your advice.

2

Do you mean that the user is not signing out when a Job finishes?
To get a quick understanding of the current situation, I suggest checking the sign-in/sign-out history during a series of Job runs in the OS Event Viewer to see what behavior is occurring.

3

@Yoichi,
Thank you for your reply.
I checked in Event Viewer, and the user had successfully signed out when the job ended.
Therefore, it seems the session is being disconnected correctly at the OS level.

However, when I run the process a second time on the same robot,
the Python called with “Start Process” does not launch, and the activity appears to be skipped.

4

It might be better to investigate what is happening there.
For example, you could check the logs or use Orchestrator Job Recording to understand the situation, or use the Process class instead of the Start Process activity to check the standard output and error output at runtime. What do you think?

5

@Yoichi,
Thank you.
You’re right; it would be more reliable to check what is actually happening using logs and so on.
I checked the situation with Orchestrator’s Job Recording, and it was working without any issues. However, since error output is not currently being generated, I can’t check the situation.
You mentioned using the Process class, etc., to check standard output and error output. How would I implement that in UiPath?

6

So, you mentioned “using the Process class and similar tools to check standard output and error output.” How would I implement that in UiPath?

For example:

7

@Yoichi
I ran some additional checks.
After checking with the improved code that includes logging, I found that
Python starts and runs normally on the first run, but
the Python process itself does not start on the second run.
There are no errors in the event logs or the Invoke Code output, and
the Orchestrator job is marked as “Successful”, but in reality, Python did not start and the script was not executed.

8

Since the second login is also a new login, the conditions should be no different from the first time…
Alternatively, the second launch may be happening too quickly due to the cache or some other factor. Could you add a few minutes of “wait” at the beginning of the process and check whether that resolves the issue?

9

We checked, but the result was unchanged. We’d appreciate it if you could let us know if there’s anything else we can do.

10

I’m sorry for commenting without fully understanding the situation, but…
By the way, if a person performs the same steps in the same way instead of the robot, it works, right?
How about trying it manually on the execution machine: run it once, log off, then run it a second time, and see whether it works?
If it doesn’t work that way, we can determine that the issue isn’t related to the robot.