-
Notifications
You must be signed in to change notification settings - Fork 269
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(WidgetDriver): Pass Matrix API errors to the widget #4241
Conversation
1b1a0fb
to
0dd249f
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4241 +/- ##
==========================================
+ Coverage 85.17% 85.20% +0.02%
==========================================
Files 280 280
Lines 30836 30858 +22
==========================================
+ Hits 26266 26292 +26
+ Misses 4570 4566 -4 ☔ View full report in Codecov by Sentry. |
0dd249f
to
cccf7a0
Compare
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.
Makes sense! But we need many more comments for this, please; let's try to add them as we touch these files.
452c513
to
fd15939
Compare
fd15939
to
6828ffa
Compare
(I might not be able to review this this week; if it's urgent, please ask review to somebody else.) |
} | ||
|
||
/// Create a error response to send to the widget from a matrix sdk error. | ||
pub(crate) fn from_error(error: &Error) -> Self { |
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.
Can this take ownership of the error?
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 could but would there be any benefit to that? we will only call methods that use the ref?
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.
Avoid cloning in the function's body, and it's a good practice whenever you can do that (as it avoids future changes to this code from cloning too).
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 will only call to_string
and as_client_api_error
on the error object. Both use &self
. to_string
will of course allocate new data but I am not sure there is a way to convert an error to a string without that overhead?
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.
Indeed there's no way, but overall passing by ownership makes for cleaner APIs, whenever we can do it.
/// The matrix standard error response including the `errorcode` and the | ||
/// `error` message as defined in the spec: https://spec.matrix.org/v1.12/client-server-api/#standard-error-response | ||
response: Value, |
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.
Is it really worth saving the response
field as a json::Value, instead of having the fields in there, automatically serialized by serde?
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 using StandardErrorBody
makes sense?
This struct was a bit suspicious to me see: https://matrix.to/#/!veagCdDBjKrMsOCzrq:privacytools.io/$2ieYTtk1E4HU36rQZ7r40_bjGaWUN-zfOGz01Yfv3Ng?via=matrix.org&via=envs.net&via=kabou.ro
(I was afraid it is only supposed to be used in a very special occasion since its not even used in the ErrorBody enum)
Also the ErrorBody
enum seemed to be the perfect fit here but it is not serializable.
So I did not use it before.
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.
Would it make sense to store the result as an integer and the error message as a 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.
The errorcode is a a string as well. I used the StandardErrorBody which is exactly what we expect here.
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 doesn't pass tests; I'd rather take a look after tests are passing, please! (or, if you need help with tests, please let me know and pinpoint where you need help :-))
138be77
to
6a340f4
Compare
….com/matrix-org/matrix-rust-sdk into toger5/widget-driver-matrix-api-errors
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've addressed the comments that hadn't been addressed. Please let me know when your PR is not done yet (by removing the review request, or posting a comment), so I'm not reviewing stuff that's just about to change 🙃
Currently the WidgetDriver just returns unspecified error strings to the widget that can be used to display an issue description to the user. It is not helpful to run code like a retry or other error mitigation logic. Here it is proposed to add standardized errors for issues that every widget driver implementation can run into (all matrix cs api errors): matrix-org/matrix-spec-proposals#2762 (comment) This PR forwards the errors that occur during the widget processing to the widget in the correct format. NOTE: It does not include request Url and http Headers. See also: matrix-org/matrix-spec-proposals#2762 (comment) Co-authored-by: Benjamin Bouvier <[email protected]>
Currently the WidgetDriver just returns unspecified error strings to the widget that can be used to display an issue description to the user. It is not helpful to run code like a retry or other error mitigation logic.
Here it is proposed to add standardized errors for issues that every widget driver implementation can run into (all matrix cs api errors): matrix-org/matrix-spec-proposals#2762 (comment)
This PR forwards the errors that occur during the widget processing to the widget in the correct format.
NOTE:
It does not include request Url and http Headers. See also: matrix-org/matrix-spec-proposals#2762 (comment)
Signed-off-by: