-
-
Notifications
You must be signed in to change notification settings - Fork 594
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
Map decryption errors correctly from rust #3710
Conversation
…t-r/backup/restore/pr3
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.
All looks good, thanks.
For test coverage, I think a different userId seems worth testing, hopefully this.stopped is easy to test? An event without a roomId seems worth checking too. So maybe that would get us over the threshold?
I have removed the part that was mapping the rust |
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, thanks!
The
decryptEvent(event: MatrixEvent): Promise<EventDecryptionResult>
Promise can be rejected withDecryptionError
. This is implicilty part of API as it's used in react sdk (DecryptionFailureTracker for posthog), and it's also needed to query keybackup automatically (done in a follow-up PR).This PR uses a new functionnality in wasm binding that returns typed error for decryption failures. These error are mapped to the existing DecryptionErrors.
It's not a 1:1 mapping (can we ignore the quality gate because only 75%?)as the crypto backends do not report the same errors, but it maps the important ones.
Based on #3709
Checklist
This change is marked as an internal change (Task), so will not be included in the changelog.