While testing in https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/34179, I discovered a case where the Arrow receiver can get "wedged" if the client is not calling Recv(). It is possible to arrange a test such that the receiver send loop is stuck in a call to Send() from which it will not exit on its own by writing a test that sends data without receiving batch status responses.
The data could be legitimately sent and followed by a CloseSend() before the stream max-age-grace. In this scenario, it seems the call to receiver Send() will not be unblocked by gRPC itself.
While testing in https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/34179, I discovered a case where the Arrow receiver can get "wedged" if the client is not calling Recv(). It is possible to arrange a test such that the receiver send loop is stuck in a call to Send() from which it will not exit on its own by writing a test that sends data without receiving batch status responses.
The data could be legitimately sent and followed by a CloseSend() before the stream max-age-grace. In this scenario, it seems the call to receiver Send() will not be unblocked by gRPC itself.