Doug Fawley

This should be good to go modulo the small nits/test issue. Let's be ready to iterate on the registry stuff if you find it isn't working well while implementing the...

Happened to me today. Maybe this is more common now for some reason?

> This would require updating the grpc.Stream interface to get the required codec and compressors for the PreparedMsg. Right now there is no method to access those universally for any...

The test is done. However it seems we have a bug, so the test is disabled.

If you need a short-term workaround to keep things working as they were before, you should be able to use the passthrough resolver: ```go client, err := grpc.NewClient("passthrough:///:", ...) ```...

> But there are more issues with this change. Are you saying the workaround of using `passthrough:///:` as the target string isn't working for you in these situations? If so,...

Thanks for confirming. Yes, this should be treated as a bug and the workaround was not suggested to avoid fixing it.

For reference, this gRFC comes into play here: https://github.com/grpc/proposal/blob/master/A1-http-connect-proxy-support.md But note that Java did not implement this gRFC, and we may or may not want to do things this way.

@cstockton Are you thinking of `CloseSend` on the client or the server? This bug covers client-side; I don't think you could `finish` the `clientStream` or abort that goroutine when `CloseSend`...

> Is it also a best practice to always enable client side health check if the loadBalancingPolicy is round_robin? @dfawley But I am not whether is there any performance penalty?...