@markdroth thanks for the heads up, Java will use this code starting in 1.4.

Known failures: #9542 #10576 #10582 #10481 #10643

This was an unfortunate choice. https://github.com/grpc/grpc/blob/master/doc/statuscodes.md defines RESOURCE_EXHAUSTED as being generated by both the server (full queue, out of quota, etc.) or the client (response too large). The problem with that is that, most of the time, it's OK and desirable to retry the former case, while it makes no sense in the latter. Unless responses vary between identical calls, if a message is too large the first time, it'll be too large on every retry, too. And because we're talking about >4MB in the default case, this will result each time in quite a waste of cycles, memory and bandwidth.
I suppose it is too late now for any changes. Is it recommended for clients that care simply to hard code a check against the error string that is used by the gRPC implementation they rely on?

I'll let @a11r respond to this.

Ultimately, I think this is an unfortunate consequence of having a fixed set of response codes, especially given that the same set of codes is returned by both gRPC and the application. I would not recommend that applications depend on the human-readable text strings, because there is no guarantee that those won't change over time. But I don't have a better solution to recommend.

Yes, the text string check is a very desperate last resort, in absence of a better mechanism. We're adding an opt-in to disable retries for "message too large" errors (to accomodate both the case of an hypothetical GetQueueContents() and GetQueueItem(): perhaps the client is OK with retrying the former) and it'll be treated as an optimisation. I'll have to find a way to make it work with service configs, of course.

We'll also have a test to make sure to catch text changes over time, or at least the trivial ones.