Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add handling for HTTP 429 responses #66

Closed
cuu508 opened this issue Oct 17, 2022 · 2 comments
Closed

Add handling for HTTP 429 responses #66

cuu508 opened this issue Oct 17, 2022 · 2 comments

Comments

@cuu508
Copy link
Contributor

cuu508 commented Oct 17, 2022

When pinging a check via slug, if the request gets rate-limited, Healthchecks.io can return HTTP 429 response: https://healthchecks.io/docs/http_api/#success-slug

When this happens, runitor outputs:

2022/10/17 13:15:06 Ping(start): max tries reached after try 3. last error: <nil>

It would be nice if runitor would print a more descriptive "rate limit exceeded" message here.

Note: this only happens when pinging by slug. When pinging by uuid, Healthchecks.io always returns HTTP 200, even in rate-limited cases, for backwards compatibility.

Note 2: Healthchecks.io (the hosted service) has rate-limiting, but the open-source Healthchecks project does not. For efficiency, the rate-limiting is done by nginx, so there's no sign of it in the python code.

bdd added a commit that referenced this issue Oct 17, 2022
When the retries are exhausted and the last cause to that is a retriable
response from the Healthchecks instance, that response isn't passed
around as the error to be shown to the user.

This was a bug.

Addresses #66
@bdd
Copy link
Owner

bdd commented Oct 17, 2022

This was a bug.
Added the commit above. Will cut a release soon.

@bdd
Copy link
Owner

bdd commented Oct 22, 2022

I released v1.0.0 🎉 including this bugfix.

@bdd bdd closed this as completed Oct 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants