Doug Fawley

@lulian7 - IIUC you should be able to use the workaround suggested here for Java gRPC clients: https://github.com/soheilhy/cmux#limitations

> The vet-proto step fails in the checks with the proposed changes, what needs to change to allow for them to work with the generated files now containing the additional...

> I ran regenerate.sh but it doesn't run in a container, so it uses my system's protoc version instead of 3.14.0 that's in the existing files. Would you mind downloading...

Another failure: https://github.com/grpc/grpc-go/pull/4455/checks?check_run_id=2614145850#step:8:37

Thanks for pointing this out, @jhump. We had discussed this awhile back, and knew it would be an issue, but I think we must have forgotten about it when we...

This is unfortunately not something the team has resources to spend on right now. This will require us to evaluate the existing [`grpc.ServiceConfig`](https://pkg.go.dev/google.golang.org/grpc#ServiceConfig) to determine if we should just keep...

> From the above response, is ServiceConfig being deprecated too? The `grpc.ServiceConfig` type is already deprecated, but service configs themselves are not. For documentation, which is admittedly not ideal, the...

> That's a fair point! I'm assuming you have to use the protojson package to encode it in the correct format (similar to what that documentation is saying about field...

> If I'm understanding correctly, that actually is a deprecated approach Argh, I didn't even look closely at it, but you are right. What you have is the preferred form,...

> With the above fix, someone could still hit the same issue on a 32-bit machine We could address that via: ``` if bytes == math.MaxInt { bytes-- } ```...