Element Exist Timing Out Instantly

Hey all,
I’ve got a fairly large suite of automations I am building for regression testing purposes. I have a large library of components that I have built to function in our QA/DEV environments, and am able to execute all of the tests built with this library in our QA/DEV spaces without issue.

However, a recent production change is requiring me to run these automations against a Production instance, and some of my automations are failing inexplicably.

Most notably, I have an Element Exists activity with 3000ms timeout in a loop that waits to see if an Internet Explorer window opens containing a report. In Dev/QA, this works perfectly well - the report usually takes ~10 seconds to open, so the loop executes a few times, logging the search each time (logging is why I use a short timeout in a loop rather than one longer timeout). If the search fails 40 times (giving time for a long-running report to finish), an exception is thrown.

The issue is that when running the same activity against Production, the Element Exists activity returns a false instantly. Looking at the logs, I can see a False being returned and the loop executes 40 times in less than a second, throwing the exception before the report tab even has a chance to open. I’ve manually validated that all the selectors are valid - if I add long delay activities before the Element Exists, it finds the elements just fine.

image

image

The issue also doesn’t occur with an activity that isn’t contained in a library - I built a stub workflow that just executes the report and executes the loop checking for the IE window, and it works perfectly fine against the production instance. The problem only seems to be happening with the compiled activity, and only when running the automation against this one environment.

Does anyone have any ideas of what may cause the Element Exists activity to return an instant False without waiting for the configured timeout? Thanks for any advice you are able to offer!

Hi @AaronTank

Based on 3000 ms timeout and looping 40 times, gives 120,000 ms [2 mins] timeout. You should add 1 sec delay after your Element Exists to get the 2 mins timeout

I just used 2 minutes as an example; the exact time isn’t extremely important, as the issue isn’t how long the timeout is taking to complete, but rather that it returns False in less than one second and ignores the timeout completely.

I have the workaround of using a delay to force the timeout, but I’d rather it just work correctly.

The timeout did not take effect because element does not exist which immediately goes to next activity increment tryCount

it should wait for 3 seconds before returning false. That’s what the timeout is for.

1 Like

did you try republishing the library? Something might have messed up.
Also a retry scope is more suitable for what you’re trying to do.

Yep, I’ve republished a few dozen times with various fixes. The workaround that’s finally gotten it moving is a branch that, if the first Element Exist fails with the Prod instance active, sets a hard Delay then uses a Find Element activity to search for any Internet Explorer window and plugs that into the Element Exist. It’s hacky and gross but it’s gotten me past this issue, at least.
I’ve not used Retry Scope, I’m just used to using loops from other projects; I’ll give that a glance and see how it works. Thanks!

Hi @AaronTank

Glad that you have it figure out. Sometimes rpa bot behaves unexpectedly in production environment. I usually have a zero second delay define in the config file [dataType: dictionary(Of String, Object)]. Using a config file allows production changes to be made without requiring to go back to Dev/QA. If the robot execution logs indicates an issue with the element I can change the delay from 0 to 3 seconds.