Cancelling browser operation throws an error

@2aozturk You’re right! I encountered this error when I used a Parallel activity and set the Isolated property on invoked workflows within the parallel activity.

Is this a UiPath bug?

Actually it depends on what perspective you’re looking.

If anyone wants to use parallel threads then she/he needs to make sure using thread safe variables/objects in each thread otherwise accessing the same object at same time by different threads will cause failures in any of the threads. I think this is exactly what is happening in this case. Cancelling thread can’t be cancelled because cancelling activity is trying to do something with non-thread-safe variable/object. Usually in this case the only affected thread should be the failed one and all the other threads should be working fine but because of the nature of Parallel/Pick activity any failed thread will cause the Parallel/Pick activity itself to fail. Unfortunately this is not something we can manage completely with try-catches or any other methods because the exception is being raised in a place that we can’t catch. UiPath needs to help us by reviewing it’s UI interacting activities in thread safety perspective. Until then, I’m afraid we need to give up using parallely working activities instead need to make our checks sequentially to make it sure it will work completely without these kinds of errors. I know this is causing a performance issue but this is the only thing we have. I also mainly see this problem with UI interacting activities.

Thanks…

5 Likes

Hi @loginerror. When you have a moment could you please review @2aozturk’s insightful response to the issue of uncatchable exceptions caused when using cancelling a non-thread safe activity in a Parallel activity thread in UiPath? We’re experiencing the same issue with cancellation of Attach Browser activities that are running in parallel. Interestingly, I don’t have any issue with Find or Attach Window activities when running in parallel, so I’m guessing something about the Attach Browser activity makes it non-thread safe, to @2aozturk’s point. I’m more than happy to log a ticket with Support to review, if you think that would be of benefit.

Hi @mark.bullard

Would you mind creating a sample project that reproduces this issue with a public website and then submit that project, as well as all the contextual info (like a link to this topic) via the Studio feedback feature?

Then either me or @Pablito will process it further and it will be reviewed by our engineers :slight_smile:

1 Like

Hi @loginerror and @Pablito,

Many thanks for your time in review. I’ve attached a sample project as requested that demonstrates how a cancellable Parallel activity (Condition argument set to True) with Attach Browser(s) within one or more threads results in an uncatchable exception. I’ve included a Try-Catch to demonstrate how the exception generated isn’t caught by the catch and instead results in the entire workflow throwing an exception related to the uncancellable activity.

Here is a zipped package:
TEST_ParallelAttachBrowserError.zip (20.9 KB)

Here is the sequence xaml by itself:
project.json (1004 Bytes)

Let me know if there’s any other support I can provide. I’m happy to log a ticket with Support if needed. I’ve started converting many of our libraries’ Parallel activity threads to use Attach Window or simply Find rather than Attach Browser as they both appear to be cancellable without issue. This approach works well, except that Attach Browser tends to work best when attaching using a URL root. It would be great if we could have clarity on what activities are considered non-cancellable - if UiPath Studio natively understood those activities, perhaps it could notify the developer in UiPath Studio that a non-cancellable activity was included in a cancellable Parallel activity (only when the Parallel activity’s Condition is set to True).

Thanks for providing the project, I’ve registered the bug in our tracker.

I will not be able to provide any specific timeline just yet, but our team will evaluate and prioritize it accordingly.

2 Likes

UiPath recommends the use of parallel activities to timebox UI activities when interacting with SAP. Unfortunately we are getting the same cancellation error described in this forum, but without using parallel activities we occasionally experience the freezing error that can only be negated by the use of a parallel timebox. Would be good to have this bug rectified soon.

Hi @LachlanD

Welcome to our UiPath Forum :slight_smile:

The issue is currently being internally tracked, but I cannot offer any specific timeline.

One suggestion I would make is that if you are an Enterprise customer, you could try contacting our technical support to have some direct assistance around your specific use-case. You could use this form:

Try to use invoke workflow activities in parallel branches by setting Isolated property as checked.

This may sometimes (depending on the actions you try to make) help Parallel activity not to fail even any of the branches fails but unfortunately passing complex arguments to these Isolated Invoke Workflow activities is not as easy as you can do it in usual way, please try to use simple arguments.

Bu again, I would suggest not to use UI interacting activities in Parallel/Pick branches or State Machine Transitions.

Thanks…

we have just updated to the newest version of UiPath after being behind for a year.
Suddenly a pickBranch acitivity in one of my processes started making this error. Before the update it worked fine.

While we wait for a solution, i have made this simple workaround for anyone having issues:
Pick_Sequencial.xaml (9.9 KB)
It takes an array of selectors that it looks for (element exists, timeout 1000) one at a time, retrying a number of times until it finds one or reaches the max number of tries.
After running this, you can make a switch activity, that then acts as the “branch” part of pickBranch

Just to update, this issue will be fixed in 21.4 version.

Thanks for update, looking forward to this :slight_smile:

EDIT: @loginerror this issue haven’t disappeared after updating to 21.4 Enterprise.

1 Like

Hi @Obsev

Have you also updated the activity packages to 21.4?

Yes I have. Tried with both invoke workflow and create the workflow as library, but it gives the same error when it is inside the parallel.

Strange indeed.

Could you maybe share a snippet (screenshot or a xaml file) of your use case. It would help us understand the behaviour :slight_smile:

Also, given that it is an Enterprise issue, would you mind taking it further with our technical support via this form?

I am facing same issue, any resolution for this?

I’ve got the same. Error message:

The activity ‘GetElementAttribute’ with ID 44 threw or propagated an exception while being canceled.

First question - what this ID means? Is it possible to find the exact acvitity with this ID in xaml file? Or in Studio somehow?

I used pick and pick branch to check result of processing in java app. After finishing processing robot is checking on which screen it is sitting right now. First branch trigger is a retry scope with get attribute “relative visibility”. Second branch trigger is the same but different element taken. Third one trigger is simple delay.
Idea was that robot is checking in the same time which screen is already opened and then it goes with proper commands to the next step. Third branch was created for unexpected situations and it is going all way down to the main menu of the app and then step by step is clicking his way to desired position.

Code was working great on Studio. Last night robot was working on VM via Orchestrator. It happend 4 times during processing 10 transactions.

I probably need to choose sequential solution from thrid branch (which would be slower) and not use Pick

@Yameso, you must have used the “get attribute” activity a number of times without giving them a unique name. So, let’s say there are five “get attribute” activities with default name and code throws an exception at the third “get attribute” activity, then the message would be like The activity ‘GetElementAttribute’ with ID 3 threw or propagated an exception while being canceled

We had the same issue once we upgraded the UI activities to >= v20.10. We put the activities in separate workflows which were put into a parallel activity. Each workflow is marked as isolated.

What helped us out in the end was to disable the ‘Modern Design Experience’ from the overall project settings. After that the issue didn’t occur again. I guess the new ‘Modern Design’ activities are somewhat different. I hope it helps others!

[FOUND THE SOLUTION ]
Hope I can help
Hello everyone, I came to this topic because I had the same issue. I had a sequence with the follwing scopes:

Sequence > Try Catch > Wait for Download > If > Throw

I had a mapped error that should throw an error to be caught by try catch whose catch had an log message.
But everytime this error happened, the Throw didn’t cut thourgh the Wait For Download scope, and the robot would wait the timeout period and throw the error that is written in this topic. This happens because a bug that this sequence of activities create:

Try Catch > Wait for Download > Throw

I tested it without Try Catch, it worked .(throw an exception as expected)
I tested without throw, it worked. (the timeout exceeded and it landed on the ‘Catch’ sequence, loggin the message)

So what you should do is just remove the the throw and let the robot go on and throw a timeout error to be caught later by the Try Catch activity.
Or if you aren’t using a throw (and the error is thrown by other activity), you should consider not using Try Catch.