Add DependenciesHealthcheck dependency

[RB387]

Description

Added

• Added magic_di.healthcheck.DependenciesHealthcheck class to make health checks of injected dependencies that implement magic_di.healthcheck.PingableProtocol interface

Fixed

• Inject dependencies inside of event loop in magic_di.utils.inject_and_run to prevent wrong event loop usage inside of the injected dependencies

Checklist

• Tests covering the new functionality have been added
• Documentation has been updated OR the change is too minor to be documented
• Changes are listed in the CHANGELOG.md OR changes are insignificant

[jerry-git]

Would it be beneficial if this would return information about which ones failed (and which one succeeded)? Then it would be possible to include that information in the response of the healthcheck endpoint. At minimum, I think there could be some logging inside this method about failures.

[erhosen]

Currently one of our services uses this approach: each dependency (such as redis, mongo or kafka-consumer) implements a ping method, that might raise an exception. Each of those pings has they own set of exceptions (e.g., ConnectionFailure, NetworkTimeout, OperationFailure for MongoDB), and we’ve intentionally decided not to catch them.

This approach ensures that in case of fire, we get a complete stack trace in the logs, making it easier to debug what happened.

And it also leads to 500 error status code for a typical FastAPI/Starlette server. Since these health checks are primarily designed for Kubernetes - correct status code is basically the only thing that matters

What do you think about it?

[RB387]

Would it be beneficial if this would return information about which ones failed (and which one succeeded)?

Hmm. Do we have any case where we need to know which dependencies are healthy or not?
Usually we only want to know if everything is healthy.

At minimum, I think there could be some logging inside this method about failures.

That’s a good point. I added debug logging, but I decided not to log failures since they are raised to user and user can catch them and log if needed.

But, what I’m thinking about is, do we need the ignore_exceptions argument? To ignore some concrete exceptions that are raised by some dependencies

[jerry-git]

Yeah, I guess it makes sense, at least in K8s (probes) use cases. I was just thinking that peeps in the wider community might have also non-K8s use cases in which it might be beneficial to know which ones failed. Anyway, I guess this will be sufficient for majority.

do we need the ignore_exceptions argument

At least I can't think of a real world use case in which one would like to check the healthiness of all dependencies but ignore some 🤔

[jerry-git]

🍬