Consistency Issue: Job succeeds sporadically when scheduled

I am having an interesting issue, and I am hoping someone may offer some insight or a possible solution?
I have a process that succeeds 100% of the time when i run it locally, 100% of the time when i run it on the server manually, 100% of the time when i run it as a job through Orchestrator MANUALLY, but only maybe 50% of the time when i run it through Orchestrator as a SCHEDULED JOB.
It is a job that opens up Internet Explorer, navigates to a website, logs in, inputs data, updates data, saves data, loops through a list of users to update, then exits, logs out and closes the browser. The job seems to always fail on the “exiting” process (this is when it is backing out of web pages to get to the root directory). But it fails at different points of this process, and with a few different errors.
Again, this same process runs 100% successfully in every way EXCEPT when Scheduled through Orchestrator, and even then it succeeds some times but not in others. I’m not sure the exact error message it throws matters, but here are the 2 common errors that it throws:
An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
UiPath.Core.InvalidUiElementException: The UiElement is no longer valid ---->
System.Runtime.InteropServices.COMException: Invalid UI node.

  • Process: SigUIUpdateCCNs
  • Environment: Test Environment
  • Robot: Test Robot 1
  • Machine name: RLTIUIPHTS1
  • Info: Cannot find the UI element corresponding to this selector:

Hi @MickBisson

Without scheduling are you able to do it or else try to change the selector in uiexplorer


I have run into something similar before and what I found was that the resolution that UiPath defaults to is like a keyhole 600x400 or something. That was causing me all sorts of issues because then the elements weren’t being displayed the same as they would be scrunched in weird ways or were completely missing as some websites will hide elements when there isn’t enough space for them.

I would suggest double-checking the robot’s resolution and setting it to the same resolution that you used to initially develop the solution and see if that helps.

On the same line, if the thing that you are searching through for elements is not fullscreen, that could also cause the issues that you’re seeing.

I have done both, yes. When process is manually run through Orchestrator it succeeds every time. I have also brought the process over, re-selected the buttons (updated the selector) multiple times, and re-published, it doesnt seem to change anything. Here’s a screenshot of my run history for this process. You can see that it succeeds every Manual Run, and even has a few Scheduled Runs successful, but mostly NOT successful:

That brings up a few things i can check, thank you. I had to manually edit the process to have a hotkey of “CTRL + END” to page down so that it could see the final “Exit” button it was supposed to click. It does not open IE in max window, its usually pretty small. I assumed it opened at the same resolution every time, but maybe it did not.

I need to research the resolution, you say I can update an actual Robot-level resolution? I haven’t seen an option to do that anywhere, but perhaps i can hot-key the browser-open task to open it full-screen.

In the bot settings on the Robot tab, you can change the solution:

I would suggest the Maximize Window activity for dealing with the window itself.

1 Like

Hmm…so i did get it to maximize the window before working in it but now i am more consistently FAILING due to issues with the selector and it not being able to find the buttons. This web app i’m accessing has a point in it, after inputting the data to update, where you have to click “OK” 5 times to cycle through each page of data to update, and then after the 5th “OK” click, the save-all happens and it brings you back to the user-lookup so you can loop through the next user (this is a very old web-app lol…).

The 5 different “OK” buttons, while technically all on different pages, all have the same exact markup:

Also the SELECTOR is the same on all 5 “OK” buttons, but it also always seems to be able to find the button when i click “HIGHLIGHT”:

So i believe this has something to do with it randomly failing to find the button. Sometimes it fails on the 1st “OK” button click, but mostly its on the last, the 5th, button click:

Is there a way i can fully-qualify the selector?

For the title of the page, it says “signature” and then some data which I am assuming is like a claim number? If that’s the case, you may want to try “signature -*” so that it can capture any window with that partial title. You may want to try playing around with different things and seeing what works. Try adding intermediary elements from the page.

I find that the UI Explorer will sometimes give me more stuff to play with than what I get when I initially do the selector, maybe try that as well?

the title of the page is actually "Signature - " Plus a Profile name. I’ve checked and the Title never changes once i’ve logged in, no matter which page i navigate to or what i am doing. I will try looking around with UI Explorer, i have opened it a few times but was unsure of what i was looking at. I will say, though, that i have had to manually re-select each of those “OK” buttons a few times now. It seems to get it working for a short amount of time, then its back to issues.

The strange thing is: I’m looping through a CSV file while navigating this website (the csv file has user names and data fields to update on the website) and the process can loop through 10-15 of the users in the file before erroring out.
Meaning that the process can loop through the website (which includes 1 link click, 3 text inputs, 3 more button clicks PLUS the 5 “OK” Button clicks) 10-15 times without issue before failing once. Each loop is identical to the last, so it has no problem with these 5 possibly ambiguous “OK” Button clicks many times in a row before deciding not to find it an 11th or 16th time…very odd.

I’d like to post an update to this. The issue still isn’t fully resolved, however more fully-qualifying the “OK” button clicks using UI Explorer seems to have reduced the failure rate from 1 out of every 2 or 3 runs to 1 out of every 6 or 8 runs. It is an improvement however i am still getting this issue.

It is still very odd to me that this process runs 100% successfully when run manually in Orchestrator or manually on the server but only fails when run through the Scheduling…

Also make sure LogonToConsole is False for the Robot:

There is no difference between how it is triggered, but it makes a difference if you are logged in monitoring it versus it running truly unattended.

It’s most likely a coincidence, but I’d be interested to see what the errors were in that image you showed where they were failing.

The “UiElement is no longer valid” error is a tricky one to solve, because that means the website is acting weird. If you are using Attach Browser, try using Attach Window instead. Or if the code is inside an Open Browser, then try placing it outside of it inside an Attach Window. You can also try placing the code outside of the Attach Window and use all full selectors instead of partial selectors. - I’m suspecting there could be an issue with the parent selector in the Open or Attach activity. Additionally, if you are using Chrome, maybe the website is not performing well in it and needs to use IE, or vice versa.

Without actually working with the website, it’s kind of difficult to solve, but hope those ideas help figure something out.


1 Like

I have updated the robot to not log in to the console, however it does not appear to have changed the run success rates. You may be correct in the login though. It uses a service account login to access the server and run the process, and half the time i am either only “disconnected” from the same server with the same login or I sign out of the service account. It may succeed more frequently if i remember to sign out of the user instead of “disconnect” only.

When it fails, I need to log in as the service account and properly log out of the website it is accessing otherwise the future attempts will fail on the login step. I’m sure there may be a way to do this automatically but i am unaware of how to do it, so for now i am doing that roll-back on error manually.

Here’s a list of the last 11 runs today and their errors. For testing purposes only i have it set to run every 15 minutes from 7am to 5pm M-F.

  1. Successful
  2. Cannot find the UI element corresponding to this selector
  3. Cannot find the UI element corresponding to this selector
  4. Cannot find the UI element corresponding to this selector
  5. Success
  6. Success
  7. Success
  8. Success
  9. Success
  10. Click generic error.
  11. Success

I suggest taking a screenshot when an exception occurs (which is good practice) or infront of when you suspect the error occurring while debugging the unattended mode. I have solved so many problems just by having a screenshot ready to look at to see what was happening.

1 Like

I believe most of the issues have finally been taken care of here. I have had 6 successful scheduled job runs in a row, but will continue to monitor today in case anything else pops up. Here are my findings:

Per @dmccammond , I used the UI Explorer to more fully qualify my Selectors. It turns out this was a mistake, however, for SOME of my Selectors. It turns out one or two fields in the process actually move around a bit on the page occasionally, depending i think on the data loaded. Because of this, i was actually getting consistent failures after fully qualifying my Selectors. I found the one Selector it was always failing on, though, and instead i UN-fully-qualified this specific Selector (leaving only webctrl’s id and tag parameters). This seems to have fixed all of my issues up to this point.

I also, for a similar issues that popped up maybe one out of every 10 runs, put a delay of .5 seconds on every button click event, as sometimes the job would move faster than the web page could keep up.

Thanks again for all your help, I will close out this issue by end of day today if it continues to run successfully.

1 Like