Retrying pings and ignoring failed pings

[rudolfbyker]

At first I wrote my own simple client for healthchecks.io with just the minimal features that I need, but then I thought, someone must have done this already, so I searched and found your project. It's very clean and easy to understand, so well done.

Is your feature request related to a problem? Please describe.

My client does two things which I'm missing in yours, which is preventing me from throwing away mine and just using yours:

• Retrying pings (by wrapping the requests.request function in a tenacity.retry decorator for all requests that are safe to retry (basically all of the ping API and some of the management API).
• Ignore ping failures (because we would rather see a failing ping on the dashboard than crash the script). This is especially useful when monitoring scripts that don't need an internet connection to finish their job, but just use the internet connection to ping, and that connection is sometimes flaky. We would rather let the script finish and have a false positive on the dashboard, than let the script crash. An example of this is a backup script running on a VM somewhere.

Describe the solution you'd like

There are a few possible options:

• Make the request back end pluggable – instead of this client prescribing the use of httpx. This can be done with proper typing by defining a Protocol with a __call__ method stub.
• Keep using httpx, but wrap some calls in retries using tenacity AND add a flag to the client contructor and/or to specific methods to ignore all errors.

Describe alternatives you've considered

• Monkey-patch the check_response and check_ping_response methods of your client. :/
• Keep using my own client instead of contributing to yours :(
• Let my backup scripts fail when the internet is flaky due to pings not going through :(((

Additional context

N/A

[andrewthetechie]

Hi @rudolfbyker, thank you for the issue.

At this point, this library is in maintenance mode. I am not actively using healthchecks.io anymore in my workflow, so I am no longer using their API daily. I will review PRs if you are interested in contributing.

I am not a big fan of adding retries to the library itself. I would leave that to the user. Could you wrap calls to success_ping or fail_ping in a retry wrapper in your code? They both raise unique exceptions you could use to control the retry behavior. You could also catch the exceptions in your script for when your internet is down and not fail there.

I think the pluggable backend is the best route to go if you want to contribute.