Rational behind mapping HTTP 429 to gRPC UNAVAILABLE

[Trustin Lee]

Hi,

According to http-grpc-status-mapping.md, HTTP 429 Too Many Requests is translated into gRPC UNAVAILABLE rather than RESOURCE_EXHAUSTED. However, at some point in the past, statuscodes.md said RESOURCE_EXHAUSTED. Is there any reason the gRPC team changed the recommended mapping for HTTP 429 status? Why is UNAVAILABLE is better than RESOURCE_EXHAUSTED for HTTP 429?

I'm asking this question not only to solve my own curiosity, but also to give a better answer to the bug report for Armeria's gRPC status code mapping that merely follows what grpc-java does.

Thanks,

T

[Eric Anderson]

google/rpc/code.proto has the HTTP mappings. Those are REST-centric and are for converting to HTTP status code. Multiple of them are obviously wrong for gRPC (e.g., NOT_FOUND→404) and multiple of them are... weak... mappings even with REST. They aren't used for gRPC as gRPC (currently) always uses 200 for RPC errors. (I would be interested in changing that, in particular for UNIMPLEMENTED, but it hasn't been a problem.)

http-grpc-status-mapping.md is the opposite. It is HTTP → gRPC status code. HTTP 429 could be mapped to RESOURCE_EXHAUSTED, but I don't think UNAVAILABLE is bad. There was some discussion on the PR about this specifically after it was merged: https://github.com/grpc/grpc/pull/4955#pullrequestreview-6858335 . The current mapping was trying to be "good enough," and was thought to be the first pass. I'm quite surprised it has been 8 years without any change.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/24702a70-915d-41d5-a9a1-e477bfaf8a05n%40googlegroups.com.

[Ravi Kodippili]

> gRPC (currently) always uses 200 for RPC errors

I wanted to confirm that servers should return a 200 HTTP status code regardless of gRPC status. I believe this is the case but I didn't find https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md to be explicit about it.

[Michael Lumish]

In the responses section of that protocol doc (https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md#responses), the "HTTP-Status" production is exactly the string ":status 200". This explicitly means that gRPC servers must always return a HTTP status code of 200 in any gRPC response.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/805eb44e-fa31-481f-8231-71071e87e99fn%40googlegroups.com.