Most of the logic implemented in useInitialNotificationsEncryptedMessage hook in native folder can be reused for olm session initialisation on web. That said the shareable part it should be moved to lib and only the platform specific part should be kept in native. Additionally this differential introduces necessary changes in native components (mostly boilerplate code).
Details
Details
Using native app ensure that brand new olm session for notifs (select * from olm_sessions; in mariadb console) is created when:
- Logging in.
- Registering.
- Registering with siwe.
Additionally repeat the second part of test plan for D9532 but for native app.
This will ensure that existing functionality relying on olm data on native isn't broken by this differential.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Realize this is mostly a refactoring diff, but wonder if we should add some error handling or at least logging to useInitialNotificationsEncryptedMessage? Maybe as a follow-up or something
| lib/shared/crypto-utils.js | ||
|---|---|---|
| 29 ↗ | (On Diff #32186) | Should we do any error handling in this callback in case any of the steps fail? |
| lib/shared/crypto-utils.js | ||
|---|---|---|
| 29 ↗ | (On Diff #32186) | On native this function is used during log-in. That said if it fails then we let the entire log-in fail. This is something we agreed on during work on encrypted notifications. We could try ... catch and let notifications session be created via socket request. However it would probably have similar effect as to simply remove it from log-in and put the responsibility to create notfications session on the socket request which would be retried in case any of those steps fail. So the basic question si whether we want to let the user log-in even if they can't establish notifications session instantly. Additionally this is lib code so it can be argued whether the actual caller of this function will know better how to handle its failure. This is something I could discuss with @ashoat during 1:1. |