How to detect errors from the OpenWeather API and stop my rule?

SharpTools.io (web)
1

Hi all,

I am using the OpenWeather API to get weather updates. I have a rule that will send the API call, parse the response, and then update a series of variables for metrics like the current temperature, wind speed, chance of rain, etc. It’s been working great for a long time, but 2 days ago I got an alert from OpenWeather telling me that I had exceeded 2000 calls in one day and they’d temporarily blocked my account. I believe what happened is OpenWeather API had some issue for some period of time, and during that time, my rule fired repeatedly over and over with no break, because it couldn’t parse the failure response. That then led to the suspension and hence the failures continued until the next day. It’s all solved now because I disabled my rule and waited until the next day. Now the response is valid and hence the rule is working properly and waiting the 15 minutes I prescribed to run again.

What I want to do is detect an invalid response from the API and interrupt the rule so it won’t immediately retry (it should wait the 15 minutes and then retry). I’d also like to send myself a notification that the API response was invalid. I don’t think it makes sense to look for a certain failure code because I want this alternate flow to happen if the response is invalid, no matter what the invalid response may be. Is there a way I can add something to my rule to do this?

Here is the opening part of my rule where the OpenWeather API call is made, and then I start setting variable values based on the response. How do I detect that the response is not valid?

image
image1189×1261 28.8 KB

2

The following articles might be help to you.

The first one links to the HTTP Response section of the main HTTP Rule Action article describing how the HTTP Action includes the response data, status code, and error message that can be useful.

The most common approach when dealing with third party APIs with concerns about erroneous responses is to check the status code or the response data / error depending on how the API responds.

The second link is a more general purpose guide for Troubleshooting HTTP Action Responses but it shows real examples of using the data that gets returned by the HTTP Action for troubleshooting.

–

As with any troubleshooting effort, following the steps and tips in the Effective Ways to Seek Help and Troubleshoot guide is recommended.

Based on your screenshot, I don’t see any reason why the rule would retry things. A failed HTTP Action should not inherently cause the rule to retry. Nor does a failed expression where the resulting value would be something like «expression evaluation error», but the rule would otherwise continue.

That being said, I can’t see the rest of your rule nor how it’s triggered. Note that we do not officially support or recommend the variable looping approach. I know it’s a common approach in the community, but it’s not without its downfalls, especially if it isn’t configured with some general best practices in mind.