Skip to main content

I am curious if anyone else has seen this. I inherited a bot that manipulates the UI of a medical provider webpage. I was told the bot has been failing in production for a long time, but the errors (due to insufficient logging) were vague at best. After troubleshooting the process I found the issue is not that the bot is failing but that it hangs, and I have narrowed it down to a particular step.

The step in question is a simple Recorder step that clicks on one of three tabs (below). It seems from time to time the window closes or the tab is somehow not found.

 

The interesting thing is the step completely ignores the timeout that is set. It simply hangs at this point and does not error out.

 

In the production run of this bot, I found an instance where it stayed - stuck at this step - for days, while other bots filled the queue waiting to run. I have since added a timeout of 120 minutes under this bot’s settings page, and it is at least failing out now. But what I do not understand is why it is ignoring the timeout.

In testing a possible resolution, I have recaptured the step multiple times with no change in behavior. I have confirmed that all other Recorder steps in the process fail as I would expect them to. I have then tried to put the Recorder step inside a If Recorder Object Exists loop that should wait 10 seconds and then fail if it does not find the element. I have also tried simply wrapping it in a Try/Catch and failing after 10-15 seconds. All attempts have the same behavior; this step simply sits there waiting until I manually cancel the bot. Just curious if anyone has ever encountered similar, or has any idea what might cause the step to ignore the set timeout 

Hi @JLogan2024 ,

 

I have experienced this behaviour with the advanced system time out settings on the recorder.

Because of this, I use the basic system time out which seems to do the same thing as you’re doing here. I apologise if I am wrong, but I believe the only time you need to use advanced timeout is when you wish to skip the exception and proceed to next command.

It’s not ideal to avoid using this feature, but have you tried this already?

 

Regards 

Hey there, we have had similar issues in the past and what worked for us is having a longer delay on both the red boxes. 

As a best practice, we use 60 seconds in the first box and 30 seconds in the second one. you could also try selecting different object properties to see if that stabilizes it a bit more. 

 

Thank you for the suggestions. I should have mentioned that I have tried both the basic and advanced timeouts; the latter was just what was up when I took the screenshots. As to trying the advanced settings, I have tried multiple timeouts from 5 seconds up to 120, but the behavior has not changed regarding hanging.

In the end, as I know opening a support ticket will earn me nothing (I have some tickets old enough they’re almost ready to start kindergarten), I’m going to just have to stick with the bot timeout setting. I see roughly 10% of this particular bot’s runs hang, and the timeout at least prevents them from keeping other bots in the queue from running.

Jumped on a call with support today, and walked through a number of different scenarios. It appears that the code for the Window Exists action looks first for a Chrome (or Edge, or whatever Browser you’re using) process, and then for the window title.

So, in scenario 1: if you have Chrome open, but the Google webpage is not up, the 10-second timeout works as expected.

However, in scenario 2: If Chrome is not open, and the Google webpage is not up (obviously), the code waits 60 seconds for Chrome to start before beginning the 10-second timer

I think a more common-sense and intuitive approach would be to start the 10 second timer immediately, so if Chrome is not open in 10 seconds or the page is not loaded, fail. Put in a bug fix request for this, the reasoning being that if you’re doing this check multiple times throughout a large process (which I am) you can end up adding many minutes to the total run. Not holding my breath on it being prioritized any time soon. 

Continuing to work with the product team in the hopes this bug will be fixed. In the meantime, the following two-step can be implemented as a workaround (ugly, I know):

If <path to browser> Application is Running AND If Window/Object Exists:

 

Reply


Terms & ConditionsCookie settings