grpc UNAVAILABLE status returned when calling grpc-json rpc with invalid Number (Long, Integer, ...)

[xhanin]

When using HttpJsonTranscoding with grpc, if we call an rpc with an invalid value for a number, we get a grpc status UNAVAILABLE and no log, which makes the diagnostic very cumbersome.

Exemple:

service MyService {
    rpc TestArmeriaGrpcIntFailure(TestArmeriaGrpcIntFailureRequest) returns (TestArmeriaGrpcIntFailureResponse) {}
}

message TestArmeriaGrpcIntFailureRequest {
    int64 number = 1;
}

message TestArmeriaGrpcIntFailureResponse {

}

Create an armeria server with this proto file, enable HttpJsonTranscoding, and call

curl -XPOST -H 'content-type: application/json; charset=utf-8; protocol=gRPC' http://localhost:8080'/MyService/TestArmeriaGrpcIntFailure' -d '{
  "number": 10.12
}'

We get:

< HTTP/1.1 503 Service Unavailable
< content-type: application/json; charset=utf-8
< grpc-status: 14
< content-length: 37
< server: Armeria/1.26.2
< date: Wed, 10 Jan 2024 15:21:11 GMT
<

{"code":14,"grpc-code":"UNAVAILABLE"}

Note the 10.12, which is a valid json Number, but can't be parsed to a Long.

I've tried to check the source code, and I see that a Long.parseLong is used, and it seems the NumberFormatException raised is catched here:

armeria/grpc/src/main/java/com/linecorp/armeria/server/grpc/HttpJsonTranscodingService.java

Line 572 in 30c9718

try {

still I don't know why it results in a UNAVAILABLE status, but at least it would be nice to be able to log something in such case (or have a custom mapping exception handler).

[eottabom]

I think it's the wrong request.

To use HttpJsonTranscoding, the HttpRule must be defined.

import "google/api/annotations.proto";
service MyService {
    rpc TestArmeriaGrpcIntFailure(TestArmeriaGrpcIntFailureRequest) returns (TestArmeriaGrpcIntFailureResponse) {
        option (google.api.http) = {
            post: "/test/armeria" // Add path
            body: "number"
        };
    };
}

message TestArmeriaGrpcIntFailureRequest {
    int64 number = 1;
}

message TestArmeriaGrpcIntFailureResponse {
    int64 number = 1;
}

curl -XPOST -H 'content-type: application/json; charset=utf-8; http://localhost:8080/test/armeria -d '{
"number": 10.12
}'

client (rest call) -> (in server) grpc transcoding -> (in server) gRPC call

gRPC code 14 = The service is currently unavailable. This is most likely a transient condition, which can be corrected by retrying with a backoff. Note that it is not always safe to retry non-idempotent operations.
https://grpc.github.io/grpc/core/md_doc_statuscodes.html

I think it would be good to refer to this.

https://github.com/line/armeria/blob/main/grpc/src/test/proto/testing/grpc/transcoding.proto

https://github.com/line/armeria/blob/main/grpc/src/test/java/com/linecorp/armeria/it/grpc/GrpcHttpJsonTranscodingServiceAnnotatedAuthServiceTest.java

https://learn.microsoft.com/ko-kr/aspnet/core/grpc/json-transcoding-binding?view=aspnetcore-8.0

[xhanin]

My description was probably not clear enough, sorry for that. The option (google.api.http) is not required, we already use the json call successfully as long as the number value can be converted to a Long.

This works:

curl -XPOST -H 'content-type: application/json; charset=utf-8; protocol=gRPC' http://localhost:8080'/MyService/TestArmeriaGrpcIntFailure' -d '{
  "number": 10
}'

This doesn't work:

curl -XPOST -H 'content-type: application/json; charset=utf-8; protocol=gRPC' http://localhost:8080'/MyService/TestArmeriaGrpcIntFailure' -d '{
  "number": 10.12
}'

I'm perfectly fine that it doesn't work, because 10.12 is not a valid int64. The problem is that it fails with nothing in the logs, no option to catch the conversion failure, and a misleading 503 http error code. It took us several hours in a production environment to figure out why we were getting 503 errors, first investigating the servers and networks stability, before noticing that the caller had just added decimals to the number.

Does it make more sense with those additional details?

[ikhoon]

The invalid input causes InvalidProtocolBufferException which is a subtype of IOException.
IOException is translated into UNAVAILABLE.

armeria/grpc/src/main/java/com/linecorp/armeria/internal/common/grpc/GrpcStatus.java

Lines 143 to 144 in 7f30250

	return Status.UNAVAILABLE.withCause(t);
	}

You can use GrpcExceptionHandlerFunction as a workaround to convert InvalidProtocolBufferException to a proper gRPC status until we fix it.

[xhanin]

Thank you for your investigation and the workaround!

[jaeseung-bae]

INVALID_ARGUMENT seems a proper return code among other codes(https://grpc.io/docs/guides/status-codes/).
Is it okay to return INVALID_ARGUMENT when InvalidProtocolBufferException is thrown?
Can I try?

• InvalidProtocolBufferException: Thrown when a protocol message being parsed is invalid in some way, e.g. it contains a malformed varint or a negative byte length.
• INVALID_ARGUMENT: The client specified an invalid argument. Note that this differs from FAILED_PRECONDITION. INVALID_ARGUMENT indicates arguments that are problematic regardless of the state of the system (e.g., a malformed file name).

[ikhoon]

INVALID_ARGUMENT sounds good to me.