Generated client stubs for bidirectional streaming service does not appear to exert back-pressure on send

[SoftMemes]

trafficstars

I have a bidirectional streaming service and want the client to block rather than buffer when producing requests. According to https://github.com/grpc/grpc-kotlin/issues/385, this should be supported, but this does not appear to be the case.

I have been able to test this by pausing the remote gRPC service, and observe that the client still pulls from the request flow, rather than stop consuming from the flow until messages have been received by the remote.

I have traced this to https://github.com/grpc/grpc-kotlin/blob/master/stub/src/main/java/io/grpc/kotlin/ClientCalls.kt#L249. I note that there's a check here for readiness, but this appears to be checked only once - there is no way for the readiness instance to go from "ready" to "not ready", so the streaming sender currently never suspends.

Is this intended/expected behaviour?

[lowasser]

I'm not sure I follow how you're reading the code. The conflated channel in the Readiness goes from ready to not-ready whenever the single element in the channel is received, and the code in ClientCalls that you point out waits for readiness before collecting the first element from requestFlow, and again after sending each element before returning control to requestFlow to collect the next one.