I have a process that loops loops through a series of tasks that have it running around an application timing how long it takes things to load. The process will go through the first iteration just fine but when it hits the second iteration it freezes. I have tested this 6 times today and it freezes at the same spot every time until eventually the Robot times out. The kooky part is that if I run the process in debug mode this does not happen. It just runs to completion like I would expect.
I found this topic in which the solution was upgrading to the latest version …
But I did that last Friday. Is the problem that I built my process on an old version? Is this a written about somewhere?
Try putting required delays in the process , version 2018.1 has memory management issues ,try clearing the variables (huge data tables for example ) if they aren’t required in the process after certain steps .
Do you mean you run it from Studio as attended? Can you identify the activity where it gets frozen? Also, when you say “freezes”, do you mean it never throws an error and just gets stuck, or does it throw an error and stop?
If you can show what the activity is (and activities right before it), the properties you have set for that activity, and any errors that occur, this will help anyone who tries to help solve your problem.
It’s most likely a timing issue, which can be solved by adjusting the properties of the activities.
I am assuming it is skipping over the click the Quick Inquiries button, but thinks it is successful.
Do you have “SendWindowsMessage” or “SimulateClick” checked? Sometimes those are not compatible and does the click but doesn’t actually click.
If that’s not it, then it is difficult to solve without seeing the web portal that it is interacting with. However, I can make a couple suggestions. First, I would watch it in run mode and see if it does click the button successfully, then see what the site looks like… there’s a chance it is working as intended but it just loads longer so you need to change the TimeoutMS for the TypeInto longer. If it is not clicking the button (but moves the mouse to it trying to click it), then there’s something before it that causes the website to load longer so you would need to wait until an element is found or attribute is a certain value before Click the button, so the website is in the correct state.
An alternative to this would be to place a Retry Scope around the Click and TypeInto, so when the TypeInto fails, it tries to Click the Quick Inquires button again. - I don’t know how I feel about this method without seeing how the web portal works.
I don’t know if it still is, but Debug used to run much slower than in Run mode, so at times it would be more successful, until the properties are all set for a reliable execution in Run mode.
I think the design here is important. What this process does and run through an application and do a bunch of checks (8 in total). Once it finishes those checks it loops through them again and again until the loop ending condition is met which in this case as a fixed number of iterations. This process does run through the first iteration successfully. The second one is when it freezes up and it always freezes up in the same spot (this succeeds in debug mode).
When I watch the process it does do those clicks on the buttons and I validated this because once the bot times out and stops because it cannot find the type into object, the App navigates to the page that it should navigate to after licking those buttons. It is as if the Bot and the App are competeing for resources that are not an issue if ran in debug.
I double checked for simulated click being set and it was not thought simulated type was set for the type into activity so I unchecked it to see if that made an impact but it did not.
As a note, if I stop the bot immediately after it does its button clicks, the next page of the Application loads up fine which would seem to mean that something the bot is doing is break itself, but that could be wrong.
I put a retry scope in there to retry the Type Into but it just retries 3 times and then the bot times out.
I really think someone needs to actually examine both your workflow and the web application you are trying to automate in order to figure out a solution. This is because you say it works in Debug but not in Run mode. I feel like it’s how the application loads after you click the button. Make sure you have set a large enough TimeoutMS property on the TypeInto where it fails, so it gives it enough time to look for it. - Also, sometimes you need to change the WaitForReady to None.
I’m sure it’s solvable though. To get UiPath’s support I recommend using this link: Tech Support
You can also PM me but I don’t work for UiPath
I meant to do the Click inside the Retry also, so when the TypeInto fails, it tries to click the button again.
I think it is a problem with the workflow and the Application I am interacting with but I do not think it is a problem with my workflow’s design and the reason I think that is that it runs through clean the first time AND it runs flawlessly in Debug mode. I could still be a design flaw in my work but it isn’t clear to me what might be causing it there.
I set the timeouts up to 5 minutes and the bot behaved as I suspected in that it froze up, the page didn’t load so the text box was unfound, the bot timedout, the page loaded.
I figured a solution though that works in this instance. I just fire up the process with a batch file and have Windows Task Scheduler run that every 5 minutes. This isn’t a solution in all cases but it does work for me here.
And yes, I agree with you that I should take this up with tech support for UiPath.
I don’t know if this is related because in my case the problem is very random and was happening today on atleast one of our robot machines, which hasn’t been a problem until now. It would act as though it clicked a link or button, however it didn’t, so the next activity failed.
My error handling takes care of this situation very smoothly and retries that section of the process, so it’s not a big deal, but I’d like to iron out any random issues the best I can.
I tried changing Single click to Double click and/or adjusting the delay before to a second. I ultimately solved it by placing the Click and the next Click activity in a Retry scope with 0 delay and 3 retries, just to eliminate that random occurrence. This is kind of what I suggested with the Retry scope, but not to say that is the right solution for you.
Yes sir. That is why it has been so puzzling for me; doubly so because it works the first time and it works all the time in Debug mode. I was going to throw process explorer at it this afternoon and see if that turned up anything.
Sometimes a Click will not give you any error, even the button is not available and the click does not actually happen. In such case you get the error in one of following steps.
Play with “Wait for ready” first. I have seen applications that make clicking happen exactly when the activity is about to timeout, set NONE in this case.
2.Then put a highlight before clicking - this may reveal the issue, this control is smarter than Click.
3.You can also put the click into “On element appear”, which has control over Active and Visible. Do not forget to change “Repeat forever” to False, though.
Be very careful with “On element vanish” - what if the element disappears before you ever check it?