grpc-js and UNIMPLEMENTED status

[felipegcampos]

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

We are currently migrating our infrastructure to use AWS ALB with grpc protocol rather than NLB and the health checks use a path and a status code ( success code ) that ranges from 0 to 99 to determine if the service is healthy. We are using an unimplemented method just so we could get status 12 ( UNIMPLEMENTED ) to get the service healthy. However, it seems like the status is always 0 ( OK ) with grpc-js and the unimplemented status is only in the body ( unless I am doing something wrong ).

Describe the solution you'd like

Would it be possible to return the status 12 (UNIMPLEMENTED) for the request itself and not in the body?

Additional context

It seems to work fine with the C-based library.

[murgatroid99]

This health check status code that ranges from 0 to 99 seems like a separate thing from the gRPC status code, so I assume that is sent in the body of the response. If that is the case, sending that would have a different procedure than sending the gRPC request status code. So, what exactly are you doing to send that status code?

[felipegcampos]

This health check status code that ranges from 0 to 99 seems like a separate thing from the gRPC status code, so I assume that is sent in the body of the response. If that is the case, sending that would have a different procedure than sending the gRPC request status code. So, what exactly are you doing to send that status code?

The status code range is just the range of numbers ALB accepts to validate the healthy of the grpc server. The problem is that grpc-js doesn't seem to send status 12 for the request and instead it's always 0 as long as the server is up. What I meant by the body of the message is that looking at the source code I think status 12 is only sent in the body of the response and ALB does not check the body, only the request status.

[murgatroid99]

If you are talking about an unimplemented method that grpc-js responds to automatically, that response does not have a body, it just sends the status. What exactly are you seeing that is leading you to the conclusion you have drawn?

[felipegcampos]

If I start the server and run the following command it will return status 0 even if I don't have DataService.HealthcheckController/healthcheck implemented:

curl -I -v -k -X POST --raw --http2 -H "Grpc-Insecure: true" -H "Content-Type: application/grpc+json" -H "TE: trailers" http://127.0.0.1:50051/DataService.HealthcheckController/healthcheck

What's leading me to the conclusion is that when I was using status 12 to determine if the service was healthy it wouldn't work. When I changed it to status 0 it started working and getting it as healthy with ALB.

[murgatroid99]

What exactly is the output of that command?

[felipegcampos]

What exactly is the output of that command?

Sorry for the delay. I was also trying to use grpcurl but I was unsuccessful. The curl command I tried was:

➜  curl  -I  -v  -k -X POST --raw --http2 -H "Grpc-Insecure: true"  -H "Content-Type: application/grpc+" -H "TE: trailers" http://127.0.0.1:50051/DataService.HealthcheckController/healthcheck 

*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 50051 (#0)
> POST /DataService.HealthcheckController/healthcheck HTTP/1.1
> Host: 127.0.0.1:50051
> User-Agent: curl/7.64.1
> Accept: */*
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c
> HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
> Grpc-Insecure: true
> Content-Type: application/grpc+
> TE: trailers
> 
* Closing connection 0
curl: (8) Weird server reply

I just want to reinforce that AWS ALB wasn't able to find status 12 either.

[murgatroid99]

That output doesn't show any of the response from the server, so I don't see how you could conclude anything about what is in the response. It looks like curl doesn't understand gRPC responses.

You would really be better off using a gRPC-specific tool like grpcurl. What problem did you experience with that?

[felipegcampos]

It's either complaining that the server does not support reflection API if I don;t provide the proto:

grpcurl -plaintext 127.0.0.1:50051 DataService.HeathchheckController/healthcheck Error invoking method "DataService.HeathchheckController/healthcheck": failed to query for service descriptor "DataService.HeathchheckController": server does not support the reflection API

or that I need to provide a proto if I want to use -import-path option:

grpcurl -plaintext --import-path=./rpc/proto/ 127.0.0.1:50051 DataService.HeathchheckController/healthcheck Warning: The -import-path argument is not used unless -proto files are used.
Error invoking method "DataService.HeathchheckController/healthcheck": failed to query for service descriptor "DataService.HeathchheckController": server does not support the reflection API

However, as I said we don't really implement health checks yet. We wanted to check for status 12 ( not implemented ).

[murgatroid99]

Do you have the proto file? If so, why not just provide it using the -proto option?

[felipegcampos]

I don't have the proto file. If I try to provide a random one that does not implement the healthcheck method I'll get:

grpcurl -plaintext --import-path=./rpc/proto/ -proto=objectService.proto 127.0.0.1:50051 DataService.HeathchheckController/healthcheck
Error invoking method "DataService.HeathchheckController/healthcheck": target server does not expose service "DataService.HeathchheckController"

[murgatroid99]

If you're just looking for a response that a method is not implemented, for the purposes of checking whether the server responds as expected, it doesn't really matter which method isn't implemented. Just send a request for a method whose definition you do have to a server that doesn't implement that method.

[felipegcampos]

We're implementing the proper health checks now. I think it's a problem with ALB and not the library. When I enabled the grpc trace and logs I was able to see the unimplemented status being returned. Sorry for the confusion, I'm closing this request.