You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One way an olm session can get "wedged" is when indexeddb is cleared by the browser. The olm account is backed (since 77bd0d3) 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.
The text was updated successfully, but these errors were encountered:
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 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
One way an olm session can get "wedged" is when indexeddb is cleared by the browser. The olm account is backed (since 77bd0d3) 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
orOLM_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 am.room.key_request
message.The text was updated successfully, but these errors were encountered: