grpchealth-go icon indicating copy to clipboard operation
grpchealth-go copied to clipboard

Client side code

Open rytsh opened this issue 1 year ago • 1 comments

I am using these imports to call health check

	"buf.build/gen/go/grpc/grpc/connectrpc/go/grpc/health/v1/healthv1connect"
	healthv1 "buf.build/gen/go/grpc/grpc/protocolbuffers/go/grpc/health/v1"

But if I use this one and mix with grpc imports than I get issue.

panic: proto: file "grpc/health/v1/health.proto" is already registered
                previously from: "buf.build/gen/go/grpc/grpc/protocolbuffers/go/grpc/health/v1"
                currently from:  "google.golang.org/grpc/health/grpc_health_v1"
        See https://protobuf.dev/reference/go/faq#namespace-conflict

Could you show how to call this server code?

[EDIT] Generated code and replaced to original package to use it, can we do it same in this repo? https://github.com/worldline-go/grpc/blob/main/health/v1/healthv1connect/health.connect.go#L27

rytsh avatar Dec 06 '24 13:12 rytsh

But if I use this one and mix with grpc imports than I get issue.

This is a known issue with Protobuf Go -- you can only use a single package that represents the same generated proto sources. You could disable this error via the GOLANG_PROTOBUF_REGISTRATION_CONFLICT=warn environment variable (as mentioned in the link at the end of the error message).

If you are using both gRPC and Connect in the same binary, you could just use the gRPC packages for the health checks. If you want to use the same transport as for other Connect stubs to the same backend service, then I'd recommend not using code-gen for now.

So instead of generating that large amount of code in https://github.com/worldline-go/grpc/blob/main/health/v1/healthv1connect/health.connect.go#L27, you really only need this snippet. You can then invoke CallUnary on that *connect.Client value.

As far as adding API to this repo to provide an RPC client, that is certainly the right long-term direction. So I'll leave this issue open and only close it when we've added that. But for the short-term, instead of waiting on that change and a release, I'd stick with the suggestion in the above paragraph.

jhump avatar Dec 09 '24 15:12 jhump