There’s something strange with the retry scope conditioning. I have a check app state inside the condition sector of the retry activity. If the element is not found within 5 seconds, it should execute a particular set of activities and then break out of the loop. Whereas, if the element is found, it should retry the scope set in the Action sector. However, what I’ve noticed is that when setting the Wait for “Element to disappear”, no matter if the target disappears or not, it always retries the scope which is not how it should be. However, if the Wait for is set to “Element to appear”, then this works well. If the element indeed appears, it will execute whatever set of activities there are and then break out of the loop. And if the element does not appear after the set amount of time, then it will keep retrying depending on the number of retries set of course.
So, my question is how can I set that if an element is not found on the webpage after a specified amount of time, then it should break out of the loop?
I have set a quick demo to see what I mean. Download below. Demo.xaml (15.6 KB)
In my use case, I’m obliged to set it as “Element to disappear”. However, in order to force it not to loop again, I’ve set a “Terminate Workflow” activity at the bottom as the last activity, else it’ll keep looping the number of retires set in the retry scope. That means that it’s not possible to add any activity under the Check App State if “Element to disappear” is set, contrary to if “Element appears” is set which allows the breaking of the loop. If there should be any new Check App State or additional activities, they must be nested inside the parent one, and at the end of the process, there needs to be a terminate workflow to prevent looping from occurring. I think UiPath purposely loops that because the “Element to disappear” option assumes that the element must first be visible on the screen and before the timeout occurs, the element should disappear, which only then allows the breaking of the loop since the condition is met. However, in my opinion, that’s not always the case as in mine. Sometimes, the element might never appear in the first place, and hence, must still allow the breaking of the loop.
Hi,
May I suggest the usage of “while loop” , it is similar to retry scope , and has number of retries as an option . Instead of just stopping the workflow you can just “break” out of the loop.
Yes the break activity works with loop activities like the while. However, when I downloaded the demo you suggested, while debugging, it twice executed the “Target does not disappear” message box, then went to the left side, skipped executing the “Target disappears”, but executed the Break, and the showed the last message box that the loop was broken. That’s strange because the element does not appear in the first place, so it’s supposed to display the message box on the left instead of the right.
I think that’s why. When I set it to “Element to appear” and then just toggled the branch for “Target does not appear” only, it did execute the message box since the element never appeared, then broke out of the loop. There’s no need for the break activity since the condition was met.
I had just designed the workflow without taking into account of -Output of CheckApp State. The below new workflow is designed in way where first it will execute Action sequence checks if the selected element is disappeared and exit it immediately . You can change max Iterations in properties panel.
Yes it works fine. The latest demo is the same like the previous one. The boolean variable is not needed. The condition is not met because the element never appeared in the first place, hence it will keep looping to the max iterations set.
Anil_G
Terry_Marr
furkan.cosan
Matias_Clemente.Arg
saru
cgs1
SorenB
anjani_priya
Atulkant_Gaur