We are facing an issue in production with the “Element Exists” activity. Although the timeout is set to the default value, the activity returns a “False” (element not found) result within just 1 or 2 seconds. But, when we check the exception screenshots, the element is clearly present on the screen.
This issue started today and the affected processes have been running in production for the past two years.
The issue is impacted for Edge browser-based automation but, these are many other Edge browser-based automations running without issues.
It is not specific to a single web application or a particular step in the workflow.
Studio/Robot Version: 2021.10.3
UiPath.UIAutomation.Activities Version: 20.10.8
Wait for ready is given as ‘Complete’ for these activities.
Has anyone else experienced similar issue with the “Element Exists” activity in Edge browser automation?
The “Wait for Ready” setting is already marked as “Complete” and the selectors are still valid and unchanged. Also, some transactions are getting completed using the same workflow/activity when the website elements load quickly.
During testing/debugging, we did not find any issues with the activity, the configured timeout is working as expected.
How about including this element exists in a retry scope?
You can do something like below to introduce more possibility of not finding it.
include element exists activity in retry scope
set the condition as check true for element exists result variable
include the number of retries you think would be enough. May be 3 or 5? Also provide the retry interval of may be 5 seconds or whatever you feel should be enough.
set the continue on error property of retry scope to true.
Doing these steps would ensure your activity won’t fail right away, and most likely will get identified in one of the retries if was not picked initially by bot.
We currently have some limitations on immediatly updating the package version.
We are not looking for a workaround for this issue but are trying to see if someone else is facing the same problem. Also, the same version of the Ui Automation package is used for all automations in production.
The “Activate” activity is already present in the code. Since we haven’t received any other solution, we are planning to implement a retry scope with delays to resolve the issue for now.
Sometimes, issues like this can’t be explained or tracked down to its exact root cause. But usage of retry with proper retry intervals does help reduce/vanish these issues for sure. Please follow the points I have shared wrt retry usage(don’t ignore the point 4, its important - either you do this or you put retry scope inside a try-catch block else, if condition is not met even after all retries, its gonna throw an exception.)
We also follow this approach usually around the elements we can’t afford to fail to ensure more robustness.