Pick branch: Cancellation of 'Get Text' activity takes (timeout-)time

Hi community,

I am using the pick activity pretty often (after a nice introduction by a UiPath Pre-Sales-Engineer :wink: ) and after a few rounds of trial and error I felt like I got the hang of it.

Unfortunately I ran into a weird issue:
I build the following pick with 2 pick branches:

The Pick triggering works just as expected.

  1. Pick Branch 1 Trigger (Find Element) gets started
  2. Pick Branch 2 Trigger (Get Text) gets executed
  3. Pick Branch 1 Trigger completes (Element was found)
  4. Pick Branch 2 Trigger gets canceled (Get Text gets canceled)
  5. Pick Branch 1 Action gets executed and Pick is finished

Output

Strangely between Step 4 and 5 there is a 30 second break (it even shows in the JSON-Output entries), which is exactly the timeout for the “get text” activity. I can also shorten the break by shortening the timeout of the “get text” activity, so the direct connection is definetly there.
I just do not understand why the timeout of the “get text” activity needs to finished before the pick can continue, since the activity gets canceled.
I do not have this issue when I use another “find element” activity. But I had the same issue with a “get attribute” activity.

To understand my use case:
(shortened) When loading a form in SAP either a popup shows up (Notiz-Branch) or a message in the message bar gets shown.
Since the message bar element is always there but either its text is “” or “xyz”, I cannot use “Find element” on the second Branch.

Does anyone know this issue and can help me fix it?
Is it an SAP issue?
Are the “Get xxx” activities not set for being canceled in a pick branch?
Does anyone know a workaround or alternative activity?

Thanks for your help.

Hi @RPraschma

Have you tried using Get Attribute based on property text or aaname

Thanks
Ashwin S

1 Like

Hi @AshwinS2,

Thanks for your tip

I tried both:

‘aaname’ does not give me the desired text

With ‘text’ I have the exact same timeout issue.

Regards
Richard

1 Like

I simulated this scenario (delay in branch1, GetText in branch2) and it works as expected - branch2 is cancelled immediately after delay elapsed.

So problem is likely not in the Pick/Pick Branch/Get Text.

Cheers

1 Like

@AshwinS2 your tip gave me an idea:

I used wait attribute on the attribute 'text" with a “* *” as desired value.

Since it needs an UIelement as input I had to put a “find element” activity beforehand.
Unfortunately it sometimes gives me an exception when the value changes so I put it inside a retry scope:

So I found a workaround.

Thanks again.

1 Like

Hi @J0ska ,

thanks for the test.

So maybe it is an SAP issue.

I’ll leave this topic open for a week. Maybe someone else can confirm this.

Hi,

this issue is reappearing with another (more annoying) result.
When a “find element” gets cancelled in a pick branch, it first finishes its “finding” run, running in a timeout and then throwing a timeout error. Since it already has been cancelled I get the error: “Find Element with ID XX threw or propagated an exception while being canceled”

So this seems to be an actual issue of the pick/pick branch activity.
It seems not to properly cancel “get Text” or “find element” activities, but waiting for their timeout instead. Resulting in a timeout error while being cancelled.

Maybe it is also an issue in those two activities, with not handling the cancellation properly. (like saying “let me finish this find run before I cancel myself”)

Anyone else have an idea what the issue might be?

Regards
RPraschma

Hi, im having the same issue, my work around is kind of ridiculous.

Having the find element (timeout 5s) in a while untill the element is found, so worst case scenario you wait 5 seconds if any other branchs triggers.

did you found any other solution?

Doesn’t it perform each of the activities in the Pick Branch from left to right? which is why it waits for the timeout.

Sorry, it’s been a while since I looked at this activity, cause I remember exploring the issues with this activity.

I think the purpose is to assume the page is already loaded, so then there would be no wait time needed. So, if you need to wait for each element to appear, it waits for the timeout to move to the next ‘Pick’. In that case, ideally, you would want to check if the page is loaded prior to the Pick Branch, then you can use 0 timeouts and move on fast.

But, like I said, it’s been a while since I have explored the issues on the Pick Branch.

@claytonm Pick starts all branches simultaneously. Once one of the branches’ Trigger activities has run through succesfully, all other pick branch triggers are cancelled. Pretty detailed described in the microsoft docs (Auswahlaktivität | Microsoft Docs)

@rjSampaio: My workaround for the exception thrown by the “find element” activity was to create a replacement for the “find element” activity.
I put a “element exists” with a small timeout (to reduce the waiting time due to the above explained issue) inside a “retry scope” with a high repetition. If found it exits the retry scope. (The “is true” activity is from the Microsoft.Activities package)
image

And since I use it in a lot of my processes I made a custom activity out of it.

1 Like

This is similar to my solution, i use “while” not exist/found