-
Notifications
You must be signed in to change notification settings - Fork 112
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
Example of a possible fix for indicating server errors #374
Conversation
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.
The overall approach looks good! Before we merge these changes in, let's get the code that sets isServerErr
closer to the HTTP layer.
// IsServerErr returns true if the error was produced by the server. | ||
func (e *Error) IsServerErr() bool { | ||
return e.isServerErr | ||
} |
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.
I'd prefer not to export this method - we've already got connect.IsServerErr
.
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.
In that case the method isn't really needed because it's the same as inspecting the field
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.
Removed IsServerErr, can be reintroduced if we ever need it
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.
Yep, sounds right to me!
error.go
Outdated
} | ||
|
||
// NewError annotates any Go error with a status code. | ||
func NewError(c Code, underlying error) *Error { | ||
return &Error{code: c, err: underlying} | ||
} | ||
|
||
// IsServerErr returns true if the error was produced by the 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.
Let's rethink this name a little; IsServerErr
suggests to me that we're categorizing errors into 4xx and 5xx. Perhaps IsFromWire
?
Also, can we give some examples in the GoDoc? I think the idea is approachable, but a little subtle.
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.
I do like IsFromWire
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.
Although talking API design we probably want it to be IsWireErr
because connect.IsFromWire
doesn't give enough context
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.
field changed to wireErr bool
and function changed to connect.IsWireErr(bool)
for simplicity but also context around the fact that an error is still being checked
protocol_connect.go
Outdated
@@ -478,6 +479,7 @@ func (cc *connectStreamingClientConn) Receive(msg any) error { | |||
// For users to realize that the stream has ended, Receive must return an | |||
// error. | |||
serverErr.meta = cc.responseHeader.Clone() | |||
serverErr.isServerErr = true |
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.
I think we can avoid both this change and the one above by handling this closer to the wire - let's add this code to connectWireError.asError
instead.
Add `connect.IsWireErr`, so clients can distinguish synthesized from server-sent errors. Fixes #222.
Add
connect.IsWireErr
, so clients can distinguish synthesized from server-sent errors.Fixes #222.