Hi @boxcee , thank you for submitting a PR. I can't help but ask, what is the point of /ready & /health endpoints to respond with any payload and not just with response code?

Hi @boxcee , thank you for submitting a PR. I can't help but ask, what is the point of /ready & /health endpoints to respond with any payload and not just with response code?

Yeah, fair question.

1. Personal: I want to implement a health check as simple HTTP request, but cannot parse the status code as the solution. The framework doing this only allows to parse the JSON response body.
2. More general: I have been used to getting a few additional details in my health check. E.g. which component is unhealthy/unready? See the Spring Boot Actuator extension for example: https://www.baeldung.com/spring-boot-actuators#6-health-groups. I think it becomes more human readable and easier to debug.

Personal: I want to implement a health check as simple HTTP request, but cannot parse the status code as the solution. The framework doing this only allows to parse the JSON response body.

What is the framework? I think it is very weird for a framework to not allow getting a status code out of a HTTP response.

More general: I have been used to getting a few additional details in my health check. E.g. which component is unhealthy/unready? See the Spring Boot Actuator extension for example: https://www.baeldung.com/spring-boot-actuators#6-health-groups. I think it becomes more human readable and easier to debug.

This PR adds no such additional information to a health-check nor a readiness probe anyway.

I believe the purpose of having /health and /ready probes is to enable orchestration via tools like K8s. Thus adding any human-readable data there makes no sense IMO, as a client cares only if a response is 200 OK or not.

If you need any custom probes/metrics/etc, you might want to add them (guarded by a feature flag) and expose via metric reporting to some kind of monitoring. But TBH I can't think of what those might be beyond existing reported metrics.

I think it might be nice to have more information for these endpoints. I can see splitting health into several segments like sync, rpc, p2p (oneday) would be useful - especially if one can add specifics when its not-healthy.

Similarly, we could do something like that for ready. It was originally my plan to have the different components register their readiness which would then display this status on this endpoint.

However, all of this is a lot of work for not much benefit at the moment and we are unlikely to devote time to this currently.

As @sergey-melnychuk mentions, having a framework not operate on the HTTP codes at all.. is weird. Which framework is it? And can you elaborate on how you use it?

Perhaps the use of framework here is a bit misleading. I am using a home automation setup for a lot of things at home. Now I am running a pathfinder node in my local network and would like to monitor its health via the automation setup. They have a multitude of integrations for all kinds of sensors, none for this use-case though. So I am using the RESTful Binary Sensor integration. Unfortunately that one expects some JSON response to determine the state of the sensor (on = healthy, off = unhealthy).

I see it is a lot of work to actually implement the additional reporting for health and ready checks.

I am using a home automation setup for a lot of things at home.

Definitely not what I expected 😁

Unfortunately that one expects some JSON response to determine the state of the sensor (on = healthy, off = unhealthy).

Yeah I see. I tried looking through the home automation issues, but I don't see anything related to http status codes so you are probably correct.

Some options:

1. Keep a fork of pathfinder with your additions - this is of course a pita to maintain as you have to keep up with our releases each time.
2. Write a small "proxy" server that hosts /health and /ready, forwards those to the actual pathfinder node, and maps the Ok(200) etc responses to json as you need for home assistant. This should actually be relatively small and simple to do in e.g. python / rust.
3. Convince us to add json-bodies sooner rather than later 😅

I would also open an issue with home-assistant to add support for HTTP codes. Really funny to me that they support arbitrary json strings, but not the literal codes.

So I am using the RESTful Binary Sensor integration. Unfortunately that one expects some JSON response to determine the state of the sensor (on = healthy, off = unhealthy).

Would using a command_line binary sensor be an option? That way you could use curl to get the HTTP status code and use that. Like suggested here.

So I am using the RESTful Binary Sensor integration. Unfortunately that one expects some JSON response to determine the state of the sensor (on = healthy, off = unhealthy).

Would using a command_line binary sensor be an option? That way you could use curl to get the HTTP status code and use that. Like suggested here.

Hm, what can I say... Thank you! That did the trick.

Heh! Nice job @kkovaacs.

And thanks for reaching out and being proactive with a PR @boxcee.