Timeout value has no effect on path locator strategy

[revathikanakachalam]

I am using RPA.Windows library for WPF app automation.
We have a case where the page elements loading takes more than 30 secs. So I tried to get the element using by passing timeout value as 60. But looks like the element search happened for only 13 milliseconds, which i can see in report log.
Below is the keyword and report screenshot. This issue occurs only when path locator is used

Get Element ${element} timeout=${time_out}

[cmin764]

That's correct and thank you for the report!

Tech details

While the @with_timeout decorator correctly sets the timeout temporarily using auto.SetGlobalSearchTimeout(timeout), that's not affecting the children traversal given the path: strategy.

Potential solution: Improve the RPA.core.windows.locators.LocatorMethods._get_control_from_path() so it listens for the set timeout when it looks for a non-existing child and it waits until it either appears or either the timeout ticks away for the total wait duration. (assuming that the structure stays stable, otherwise we have to retry the entire path traversal every time it fails until the timeout passes or the final leaf is found)

[kkotenko]

I seem to have a similar, if not same, issue with Control Window, with this code:

Unit test Control window with Timeout
    Control window    name:willneverbefound     timeout=2.1

Here, after 2.1 seconds (plus maybe some small grace period), I would expect the ControlWindow to produce either a WindowControlError or some kind of time out error. Instead, the test waits the whole defined Timeout time (which is my case is 1 minute).

[cmin764]

I seem to have a similar, if not same, issue with Control Window, with this code:

Unit test Control window with Timeout
    Control window    name:willneverbefound     timeout=2.1

Here, after 2.1 seconds (plus maybe some small grace period), I would expect the ControlWindow to produce either a WindowControlError or some kind of time out error. Instead, the test waits the whole defined Timeout time (which is my case is 1 minute).

There's a small caveat in this keyword as it tries with two different types of controls, where the same provided timeout is waited twice (for every type of control tried). So from the logs, it looks like a global of ~30s is set and two such waits produces the total of 1 minute.

Still, this not explains why the temporarily provided 2.1s timeout isn't respected. Maybe @mikahanninen can throw a detailed look into it.