Fix grpc middleware interceptor not PostCall-ing when a streaming RPC with non-streaming server finishes successfully. #725
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Current Client-side Stream Interceptor implementation is bugged - it assumes that if the RPC is streaming, then the Server must be streaming responses too. This is incorrect, as a Streaming RPC can be either a Bidi stream ( which are currently handled properly ), or a Client-side only stream. In this case, if the RPC finished successfully, then PostCall never fires as Interceptor assumes it should get an io.EOF ( which obviously does not make sense when Server is not sending a response stream ).
This most obviously manifests when using it with Prometheus reporter - client side metrics for such RPCs that depend on PostCall ( grpc_client_handled_total, grpc_client_handling_seconds ) are not exported.
Changes
Verification
.