Bug: When use `gzip` and call with `MaxCallRecvMsgSize(math.MaxInt64)`, will read 0 byte.

[catundercar]

NOTE: if you are reporting is a potential security vulnerability or a crash,
please follow our CVE process at
https://github.com/grpc/proposal/blob/master/P4-grpc-cve-process.md instead of
filing an issue here.

Please see the FAQ in our main README.md, then answer the questions below
before submitting your issue.

What version of gRPC are you using?

master

What version of Go are you using (go version)?

1.19.2

What operating system (Linux, Windows, …) and version?

Linux

What did you do?

If possible, provide a recipe for reproducing the error.
like this demo:
https://github.com/grpc/grpc-go/tree/master/examples/features/compression
I called with grpc.MaxCallRecvMsgSize(math.MaxInt64)
And then, I got this result:

UnaryEcho call returned "", <nil>

The response message was "".

What did you expect to see?

UnaryEcho call returned "compress", <nil>

[dfawley]

I called with grpc.MaxCallRecvMsgSize(math.MaxInt64)

This is definitely wrong. The most you'd ever want to do is math.MaxInt. And even that is a pretty insane maximum. The intent of this setting is to protect you from running out of memory. No machine has 9,223,372,036,854,775,807 bytes of memory.

[catundercar]

I called with grpc.MaxCallRecvMsgSize(math.MaxInt64)

This is definitely wrong. The most you'd ever want to do is math.MaxInt. And even that is a pretty insane maximum. The intent of this setting is to protect you from running out of memory. No machine has 9,223,372,036,854,775,807 bytes of memory.

You're right, in actual business scenarios, the received data will never reach math.MaxInt. But that's not the key of this issue. Perhaps I didn't describe it clearly enough. The key of this issue is that when using the gzip compressor and configuring grpc.MaxCallRecvMsgSize(math.MaxInt), no matter how small the actual data is, even if it's only one byte, the logic in the decompressor will overflow, causing no data to be read.

I want to emphasize a point that the original available configuration of grpc.MaxCallRecvMsgSize(math.MaxInt) causes the service to not return any valid messages and there is no error reported during the call, when combined with the gzip compression method. It should be a problem that needs to be fixed, rather than asking the user to modify their previously available code.
Looking forward to your reply.

[dfawley]

As mentioned in the PR, this could be fixed by limiting the allowable values in MaxCallRecvMsgSize to math.MaxInt64-1. The PR as submitted is incorrect, as we need to be able to read beyond the configured limit to determine whether there was an overrun.

[catundercar]

Yes, it is possible to know if the limit is exceeded without reading out all the bytes. Now it looks like there is no better way to do this than to change the MaxCallRecvMsgSize parameter.😥