-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
Add some Unit tests to Abstract Client Stream #841
Conversation
try { | ||
setDecompressor(messageEncoding); | ||
} catch (IllegalArgumentException e) { | ||
inboundTransportError(Status.INVALID_ARGUMENT.withDescription(e.getMessage())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like it should be INTERNAL, since the application didn't specify an invalid argument. Instead, either the grpc library on client or server has a bug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
inboundTransportError()
doesn't actually kill the stream. And yes, that means that the other usage of inboundTransportError()
in this file is broken. It looks like they should probably call cancel()
instead now-a-days.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is invalid input, since the remote host tried to use a message encoding that the local one does not support.
cancel() cannot be called, since the javadoc says it can only be called from the application, not the transport. If there is some sort of inboundStreamError (just enough to kill the call) that would be the bets choice IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most status codes are directional. INVALID_ARGUMENT
is defined as "Client specified an invalid argument." In this case the server specified something that the client doesn't support; that isn't INVALID_ARGUMENT
.
Hmm... I'm thinking for now call both sendCancel()
and inboundTransportError()
and add a TODO to improve the situation. sendCancel()
is delayed with Netty. I'm not confident about that solution, but everywhere I look I see potential problems, and that seems the least risky.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated it to use INTERNAL.
@carl-mastrangelo looks good! Just a few minor comments. |
@@ -0,0 +1,254 @@ | |||
package io.grpc.internal; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copyright header.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, my old nemesis. Added.
@carl-mastrangelo LGTM |
PTAL |
setDecompressor(messageEncoding); | ||
} catch (IllegalArgumentException e) { | ||
// Don't use INVALID_ARGUMENT since that is for servers to send clients. | ||
Status status = Status.INTERNAL.withDescription(e.getMessage()).withCause(e); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We haven't generally been copying the message from caused exceptions. However, we should really be providing more context here anyway, so can we replace e.getMessage()
with a more clear message. Maybe something like: "Unable to decompress messages from server".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
@carl-mastrangelo, LGTM, but I had one comment. |
Thanks, submitting. |
da2030d
to
701bbe5
Compare
No description provided.