Blocking stub blocks indefinitely if client exceeds max outbound message size

[jackrwoods]

What version of gRPC-Java are you using?

1.72.0

What is your environment?

Linux - Ubuntu 22.04.5 LTS
JDK - jdk-corretto_21.0.1.12.1
Repro repository - https://github.com/jackrwoods/grpc-problem-repro

What did you expect to see?

In the console output, I expect to see "Sending message (Java)" followed by an exception/stacktrace that should interrupt and exit the application

What did you see instead?

In the console output, I see "Sending message (Java)" and an exception, but the application hangs and does not exit.

Steps to reproduce the bug

1. Clone the repository https://github.com/jackrwoods/grpc-problem-repro
2. Within the repository, run ./gradlew build
3. Within the repository, run ./gradlew run
4. Observe that the application does not exit.

---

When using a blocking stub to frame a grpc message, I am observing that my GRPC call parks the calling thread indefinitely. I always see a logged exception detailing why the request failed, but the GRPC call does not return.

I have set up a repro in this repository: jackrwoods/grpc-problem-repro. I've reproduced this behavior with a "blocking" stub (jackrwoods/grpc-problem-repro@main/src/main/java/org/example/Main.java) and a coroutine stub wrapped with a runBlocking (jackrwoods/grpc-problem-repro@main/src/main/kotlin/org/example/MainKotlinCoroutineVersion.kt). In both cases, the application hangs when the maximum GRPC message size is exceeded.

Is this user (me) error, or is there a workaround?

[kannanjgithub]

ClientCalls.blockingUnaryCall is stuck waiting for the responseFuture to be done. One time it gets a runnable given by ManagedChannelImpl that executes the call that fails with the exception thrown by MessageFramer about the outbound message being too large and the exception is swallowed. The main thread meanwhile parks itself again waiting for the response future to be completed and there are no more runnables ever added to the executor that could unpark it.

It looks like we should be putting a timeout waiting for the response future may be from CallOptions.deadline (and have the generated code have a way of accepting it), or take into account the number of unparks that would happen for a unary call.