Hi @bravenel
What is the expected outcome of a rule action http GET call timeout? Using a test URL that always times out, for demonstration purposes:
Throws an exception, therefore the rest of the rule never executes:
I've found a way to work around this with another rule and a hub variable, but it is tedious.
One possibility would be for the httpGet to be protected by a try-catch, so that the error could be caught and while it would still throw the error, and in the logs, it wouldn't crash the rule. I'll look into that.
Except I don't have a url to test with, or at least I'm not getting a timeout...
Try connecting to an IP that is non-routable?
66.66.66.66
You can use https://httpstat.us/200?sleep=30000
Note that a straight GET action seems to be fire-and-forget and doesn't generate a timeout exception. I am setting a String variable to http GET result.
I'm using that url with no timeout error.
Same with 66.66.66.66, no error.
Very strange. I tried the same test rule on another C7, running 2.3.8.140 and set up on a different LAN & internet connection, and get the same result. Here is a slightly modified version to highlight that only the Set Variable from GET (or POST) response is problematic :
Still seeing this on 2.3.9.135.
Am I really the only one seeing this behaviour (on three different hubs) ? Anyone else is game to give this super simple rule a test ?
In my case this RM feature throws an exception for anything that's not a 200 coming in within a 10 second timeout:
Throws a different kind of exception (connection error) but same same
@bravenel I still observe this behaviour in the latest 2.3.9.x release. The rule doesn't continue past the exception thrown.
I have worked around it by adding a delay to the Set Variable from GET action and either adding a Delay or Wait for Expression action after it, this way, rule execution continues.
See logs below. App 689 fails to run the actions beyond the thrown exception. App 678 has the workaround.
Actions for app 689:
Actions for app 678:
This is certainly the expected behavior for exceptions thrown. If an action fails so fundamentally as to throw an error, the rule execution can't possibly continue. As to why the action has a timeout failure, that's not something within the purview of RM.
Well, I of course cannot blame RM for Groovy's (or Java's) preference for an exception error handling philosophy for http calls, but it remains unfortunate that any non-2xx response to an http call action will cause a rule to fail to continue executing, as this is not really what I think you mean by "fails so fundamentally".
That would have been great 
Fair enough. Thanks.
OK, so suppose such a timeout is indeed a fundamentally fatal error for a rule. I don't see how to reconcile that possibility with any approach that doesn't both throw an error and have the rule blow because of it. Must be missing something...
I don't think you are. In any case, if you were to wrap the exceptions, that could (would?) break existing rules. Why I marked the topic solved.
Thanks again.
Download the Hubitat app
