Lost olm sessions due to storage being cleared are never replaced with a new one, resulting in UTDs

[bwindels]

One way an olm session can get "wedged" is when indexeddb is cleared by the browser. The olm account is backed (since 77bd0d3f3) up to localstorage (which usually isn't cleared), but the olm sessions are not. So if the olm session is lost and another client sends us a to_device message encrypted with that session, we would see either a BAD_MESSAGE_KEY_ID or OLM_NO_MATCHING_SESSION error depending on whether we have already sent an olm message from our device to their device or not.

To solve this, we should implement #629, which here would mean setting up a new olm session and sending a m.dummy message over it, and then re-request the key with a key sharing using a m.room.key_request message.

[bwindels]

One thing I haven't managed to explain is that I seem to get more UTDs when not using Hydrogen regularly on my storage-constrained phone. If these were related to the storage getting cleared, they should not be more frequent when using the app more or less.

[bwindels]

One thing I haven't managed to explain is that I seem to get more UTDs when not using Hydrogen regularly on my storage-constrained phone. If these were related to the storage getting cleared, they should not be more frequent when using the app more or less.

One possible explanation might be that my element desktop usually writes the room key to key backup and you don't notice so much. I should try to not sync for a few days on my phone but sync on my laptop and:

• verify in the logs that I received new room keys that had olm decryption errors because of missing sessions (either prekey or not)
• see whether I visually perceive any UTDs for the rooms the keys are for
• see if those keys got fetched from key backup

[bwindels]

https://github.com/uhoreg/matrix-doc/blob/olm_unwedging/proposals/1719-olm_unwedging.md