Chris, the use cases that you described make perfect sense.
However, many other users don’t expect the timeout to be enforced at the expense of failing a workflow that could succeed, given a little more time. They see the timeout as a guard to prevent the robot from retrying to perform an activity indefinitely.
That’s why our current convention is to do one complete attempt to perform the activity, before checking the timeout. Then, if the attempt fails, the robot will keep retrying until the timeout expires.
For advanced RPA devs who want to enforce a hard timeout limit on activities, there are options like the one you use, or the one mentioned by Jack Chan, or others. So far, I did not encounter a use case related to timeouts that could not be addressed with the current set of activities. If you happen to run into such an use case, please let us know.
Also, for most scenarios, in order to properly handle an error condition signaled by an expired timeout, a custom sequence of activities is needed anyway (Eg. killing the
saplogon process), so having a hard limit enforced on the timeout is not a solution alone. Usually a complete solution is composed of a hard timeout limit, combined with other error handling logic.
This discussion is not very technical, it’s more about user experience and product design . I hope I gave you some background about why the timeout is not enforced precisely when it expires and why situations like the ones described by you should be addressed like you did, with custom handling.