-
Notifications
You must be signed in to change notification settings - Fork 5
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: implement binding specific errors [WPB-14352] #771
Conversation
754fbe2
to
1d71062
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #771 +/- ##
==========================================
- Coverage 71.81% 71.61% -0.21%
==========================================
Files 107 107
Lines 19840 19896 +56
==========================================
Hits 14249 14249
- Misses 5591 5647 +56
Continue to review full report in Codecov by Sentry.
|
6f4c511
to
b9bf997
Compare
Returning an error code whose zero value indicates success is a reasonable pattern, in C. We are not programming in C. Eventually we're going to get rid of this pattern entirely. For now, we can at least use a real `Option` type to indicate whether an error in fact exists. Also, the Proteus implementation specifies that the error code is a `u16`. No idea why that got widened to a `u32`, but that was pointless, so it's back to a `u16` here.
f99601c
to
9e6b6e9
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.
Looks good! Just one thing I would have done differently in the tests
9e6b6e9
to
fadf653
Compare
Clients only care about a limited set of errors, which we enumerated in the root issue. This commit refactors the client-visible errors (in WASM) to focus only on the set they care about.
fadf653
to
11d071d
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.
Left a few comments, looks good. 👍
Clients only care about a limited set of errors, which we enumerated in the root issue. This commit refactors the client-visible errors (other than WASM) to focus only on the set they care about.
Turns out there is a whole human-written section in the TS bindings which parses the output of our error types and turns it into a somewhat better error object. That needed to be updated to handle the new, simpler output serialization.
11d071d
to
47bbc12
Compare
Kotlin tests are still failing due to previous changes, but at least the fundamental build operation is now succeeding. It's a start! Ran a Kotlin code formatter, intending only to hit the auto-generated files; turns out there were a bunch of human-maintained files in the tree also. Unfortunately, at that point, there were quite a lot of uncommitted changes. Didn't want to go through the effort of going back and unformatting the unrelated stuff, so that's all in here also.
47bbc12
to
8c34db6
Compare
What's new in this PR
Clients only care about a few error types, so let's surface those at the client interface and hide the rest.
(We can log the full detailed errors at the conversion point, but that's a separate task.)
PR Submission Checklist for internal contributors
SQPIT-764
feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764
.