New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
improve error returned by Send on server side after stream is reset #3575
Comments
There's no And can you provide more information of what client/server do in the failure? Like what methods are called, and in what order. |
Sorry, I've meant Few examples:
|
It sounds right to me for And what do you do about a sending error on the server side? The service handler should return something, but the error will never be sent to the client because the stream is already broken. |
I agree that it's mainly about a content of the error (code/message). Internal should be reserved for an actual invariant violations/API misuse. For example, it's perfectly fine to return Returning an error with the same
We usually check its code and aggregate all suspicious errors in a central storage. That's how this particular error did come to our attention. |
Maybe something like |
/assign |
@zouyee thanks for the offer. What changes do you propose to make to fix this? |
Please see the FAQ in our main README.md, then answer the questions below before
submitting your issue.
What version of gRPC are you using?
1.29.0
What did you do?
Use
SendAndClose
orSend
on server side for streaming requests. Client stream was reset by grpc stack right before that (e.g. by sending reset or by violating http/2 spec in some way).What did you expect to see?
SendAndClose
returns io.EOF or some error with non-Internal code to indicate about the error.What did you see instead?
gRPC returns an error with Internal code, indicating API misuse, while application has no way to perform correctly in this case. Any checks (including
ctx.Done()
) would have been racy as stream is reset by grpc-go from another goroutine.The text was updated successfully, but these errors were encountered: