-
Notifications
You must be signed in to change notification settings - Fork 13
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
feat: error handling overhaul #65
Conversation
5719c65
to
803b7ca
Compare
d2a1b93
to
7ecb23f
Compare
} | ||
|
||
#[test] | ||
fn error_tags() { |
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.
Rpc { | ||
code: i32, | ||
message: String, | ||
data: Option<String>, |
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.
data
field is not handled currently in Kotlin client. It should not break tho, would be just ignored.
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.
It shouldn't break but to be 100% sure can we try staging release first on the clients side?
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.
Same here, let's just share the staging url before the release, so we can test the clients manually.
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.
LGTM
Description
This reworks the RPC errors to be serializable and deserializable from the
data
field of JSONRPC error response. Both the HTTP and websocket clients in this crate make use of the new errors by deserializing relay RPC responses into strongly-typed errors.Clients in other SDKs should implement their own reconstruction based on the following JSONRPC error response fields:
code
: the general class of errors to distinguish between retryable and permanent errors;data
: the string tag specifying error kind within that class;message
: string message detailing the error.The error codes are (mostly) consistent with the old error codes & the JSONRPC specs. What's changed:
-32602
(invalid params) to a more generic-32600
(invalid request);-32700
(parse error) to-32600
(invalid request);The rest of the changes are non-breaking, in terms of error codes.
How Has This Been Tested?
Existing tests, relay integration tests and also new tests covering error tags.
Due Diligence