Feature Request: Enable gRPC Health service without BindableService beans

[nopan-rataullin]

Feature request: Allow gRPC Health service creation without existing BindableService

Problem
Services that don't yet have their own @GrpcService implementations don't get the gRPC Health service because of this condition:

@ConditionalOnBean(BindableService.class)

Could you add an option to create the gRPC Health service without requiring an existing BindableService?

Environment

• Spring gRPC: 0.9.0
• Spring Boot: 3.5.9

[dsyer]

I'm not sure I understand your premise. What's the point of a service that doesn't have a registered BindableService?

[nopan-rataullin]

@dsyer All our services are created from a gRPC template, and for consistency
we want all of them to implement health checks via gRPC that can be
integrated with Spring Actuator.

A quick dirty hack would be to implement a @GrpcService that does nothing
It's an edge solution for an edge case

[dsyer]

I might have to see some actual code to understand what you are doing. I'm not sure what you mean by a "template". Are your services somehow not gRPC services, and yet you want to register them with the health service and actuators?

[nopan-rataullin]

@dsyer Yes, exactly. Our primary method of communication between microservices is gRPC. Some services have @GrpcService implementations, while others only client-side. To avoid writing different configs for each service’s health check, it would be convenient to have a single, consistent gRPC health check endpoint that integrates with Spring Actuator for all our services

[nopan-rataullin]

Let me also explain why integration with Spring Actuator is needed. For example, to extend the standard health checks with a check for the availability of a remote resource (not in our env) - if the resource is unavailable, the health check would fail

Otherwise, we’d end up using an webserver it in some cases and a gRPC check endpoint for services that have @GrpcService, which isn’t very consistent
Or use HTTP endpoint everywhere, which adds extra overhead for services that already have a GrpcServer

[nopan-rataullin]

@dsyer Hope I explained that clearly
Let me know if you think my approach is wrong

[dsyer]

I think I need to see some code still. I don't understand what a client-side (no @GrpcService) service is. It wants to publish its health status? Or it wants to consume the health status of its remote dependencies? How is it doing that? How would enabling the gRPC health service when there are no gRPC services help?

[aditya1906]

Hi @nopan-rataullin ,
Based on the discussions, it might seem that your use-case is a pretty niche requirement, because it doesnt sound logical for a service to have a gRPC health check when there is no gRPC service implemented in it.

If that is your requirement, there is another workaround, instead of creating the Bean in every micro-service, you can create a module that has the empty GrpcHealthCheck bean and you import that bean in all your services. This might resolve the redundancy of code in all the services. Again if you can share some of your code it might help us understand the use-case, and rethink if having a support for health check with no @GrpcService will have an overall benefit, but as of now I dont think this feature adds any value overall.

[dsyer]

I may have finally understood this. You need a gRPC health service in all applications and it might be the only gRPC service in some cases, but it means that all processes can communicate their health in the same way to each other, or a platform. The net result is that you start a gRPC server and expose a single health check endpoint. What isn't clear to me is that the health check actually does anything if there are no other services running. Is it always healthy, or does it somehow reflect the status of the client stubs?

If this is correct, notwithstanding my remaining doubts about what it means, then we can simply change the way the spring.grpc.server.health.enabled property works (currently the default is true, but we'd need the default to be false), and then remove the @ConditionalOnBean guard.

[therepanic]

I will send changes for this soon

[nopan-rataullin]

I apologize for the radio silence and for poorly describing the problem - this is my first issue, I'll be more detailed in the future.
Unfortunately, I don't have much code to show except for using spring-grpc-starter, not sure if that helps.
@dsyer Yes, you understood correctly. We want to use gRPC health checks for Kubernetes probes:

• Readiness probe - k8s periodically calls the health check endpoint, and only routes traffic to the pod when it returns a healthy status (Spring context is up and the application is ready to handle requests)
• Liveness probe - k8s periodically calls the health check endpoint, and restarts the pod if it returns unhealthy or doesn't respond (application is stuck, deadlocked, etc.)
  As for your question about what happens when there are no other services - we'd want the health check to reflect the status of Spring Actuator health indicators. So we could add custom checks for external dependencies (for example ping external payment gateway) - if that system is unavailable, the application is essentially useless and should be considered unhealthy which will help us respond to issues faster

[nopan-rataullin]

Anyway, thank you so much for your attention and help