System.Environment.CurrentDirectory malfunctions in HD-Robots implementation

Hi. There’s something very weird happening to my configuration. So, I’ve created 5 HD-Robots on one single machine (namely domain\robot1, domain\robot2, domain\robot3, domain\robot4 and domain\robot5). I’ve deployed an Orchestration Process to their environment in which it uses Document Understanding and Persistence. This process is triggered by a queue. The problem is, whenever multiple users start using the process simultaneously, System.Environment.CurrentDirectory property returns the current directory of the first robot that has been initiated (which in this case, it’s always C:\Users\robot1\.nuget\packages\Containers.Certificate.Generator\1.0.80\lib\net45\) but whenever ONLY ONE user uses the process, everything is fine. Now, when every robot calls this property, they don’t get the current directory of theirs but the current directory of the first robot! I have no explanation why this is happening. Please help. Thank you in advance.

@Forum_Staff, am I facing a bug here?

Can you share your process ? Or at least share the project.json file for the process and the activity that is invoking CurrentDirectory?
What version of Robots & Orchestrator is used ?
Are you using modern or classic folders ?
Do you use a custom path for nuget packages installation path?

Here’s the project.json (2.0 KB) file.

There are multiple activities throughout the project that uses System.Environment.CurrentDirectory but the only clash happening is with one activity that it’s output results in the same file and filename for every robot. Since every robot reaches the user path for the first robot, there’s the conflict there. Here’s the Multiple Assign.xaml (2.0 KB) file truncated for that acitivity.

I’m using 20.4.1 for both. I even updated the project dependencies but that didn’t help either.
I’m using Classic Folders.
No, I did not use a custom path for the nuget packages.

I am unable to open the attached xaml. image

Since you are using System.Environment.CurrentDirectory in multiple places and only one is failing I suspect that your workflow might use some shared resources. If possible I would like to review the process. Or if you can reduce the process just to one activity where the issue is reproducible.

Also how many licenses have you allocated to the machine used for this ?

I thought you’re just going to see the error-prone activity so I removed all the lines in the XAML file but the lines for Multiple Assign acitivity in a text editor for simplification. Here’s the corrected file: Workflow.zip (34.6 KB) Theoretically, there shall not be a shared resource because every robot is using its own local path not anywhere else nor any other robot’s path. The problem is that each robot will get in return the local path of the first robot when I’m using the current working directory statement (System.Environment.CurrentDirectory).

I allocated 5 Unattended Robot licenses to the machine.

Tried to replicate in my environment the current folder result. Please observe that it is working as expected (2 different users in the same time => 2 different paths)

I found in your multiple assign that you build the path based on transactionItem.SpecificContent(“UserName”) . This can mix your users as the served transaction does not take into account the user that is requesting the transaction.

2 Likes

Please take a look these:

HD Robot on User robat1’s error:

HD Robot on Usere robat2’s error - type 1:

HD Robot on Usere robat2’s error - type 2:

The aboves are the errors raised when multiple users start the process at the same time. First, they use a process to upload some files to a Storage Bucket and send the meta info to a queue. There’s a trigger that starts an Orchestration Process that downloads the uploaded files from the Storage Bucket and goes through a moderately long workflow that has these issues in a simultaneous usage.

As you can see, Worker Robot 2 (an HD robot in robat2 userspace) is looking for a path in robat1’s user path by calling System.Environment.CurrentDirectory. This is also the case for robat3, robat4 and robat5 users.

transactionItem.SpecificContent("UserName") has no harming action since the value is being sent with an assign activity (System.Environment.UserName) in the first process that the user starts for uploading the files. It’s being used for naming paths in a Storage Bucket.

I recommend you the following :

  1. create a simple process that is just printing System.Environment.CurrentDirectory. Run this process simultaneously on all 5 robots and check the results. If this works as expected the culprit is in the workflow logic
  2. Please open a support ticket if running out of ideas :slight_smile:

@alexandru, I found the cause of the error. When the flow reaches a “Wait For Document Validation Action And Resume” activity, it goes into Suspended mode. So the problem was when there were simultaneous jobs of one unique process. And that’s because when there’s only one job, the allocation system of Orchestrator, allocates the previously suspended robot (for example robot1 here) but when there are multiple same jobs, the previously suspended robot gets started by another process. So, when the action is done and the process wants to return, it will NOT return to the first process instead it will return to another free robot (for example robot2). The variables that used System.Environment was initialized before the suspension, so they hold the values for robot1 and that’s why the local path of robot1 is always displayed in the error section of other robots.

Now my question is, how to stop the Orchestrator allocation system not to allocate the previously suspended robot?

This is expected. A job can resume from suspended on any available robot. And this allocation is done by Orchestrator without user control.

The processes must be designed in a way that does not depend on the hosting machine. You should store the file in blobstorage instead of local disks.

3 Likes

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.