Unary call can hang forever if uncaught exeception thrown in client interceptor

What version of gRPC are you using?

v1.2.0, but reproduced with v1.23.0

What did you expect to see?

If a buggy interceptor throws in onClose, gRPC logs the error, but doesn't cancel the call. This can lead to a client hanging forever. Interceptor implementations should take care not to throw, but we think gRPC could also guard against this. A deadline doesn't help, because the deadline future is cleaned up before calling the client observer's onClose method.

Reproduction: https://github.com/lihalite/grpc-error-reproduction

For instance, ClientCallImpl#closeObserver could catch runtime exceptions and cancel the call.

[ejona86]

ClientCallImpl.ClientStreamListenerImpl does catch exceptions and notify the stub for callbacks. But it does that via onClose()! If onClose() itself fails, there is no way to notify the stub things are broken. So onClose() is the one method that has this hole.

I don't think there is a way to solve this. gRPC should log the exception, but I don't know a way to un-hang the stub.

[ejona86]

Note: when onClose() is called, call.cancel() is a noop because the call is already done. There is no call to cancel.

Thanks @ejona86, that's unfortunate but understandable. We could submit a documentation patch, and perhaps change closeObserver to catch and log errors with a message that explicitly indicates client code is misbehaving (the message the executor prints when it catches exceptions is a little vague). Would that be a good resolution to this?

[ejona86]

I think that would be a good resolution.