Retry decryption of UTD timeline items #1215
Conversation
Not really necessary now, but required for thread-safe bulk updates like we want for retrying decryption.
Codecov ReportBase: 74.57% // Head: 74.49% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #1215 +/- ##
==========================================
- Coverage 74.57% 74.49% -0.08%
==========================================
Files 112 112
Lines 12800 12878 +78
==========================================
+ Hits 9545 9594 +49
- Misses 3255 3284 +29
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
| // Not using room.add_event_handler here because RoomKey events are | ||
| // to-device events that are not received in the context of a room. | ||
| let room_id = room.room_id().to_owned(); | ||
| let room_key_handle = room.client.add_event_handler({ |
There was a problem hiding this comment.
One thing to note here, this is not the only source of room keys. As your test shows there's at least one other source.
In total we have three sources:
- Receive them over to-device
- Manually import them from a file
- Import them from a backup
Your tests is using no. 2, no. 3 is another variant of 2 but not yet implemented.
I'm fine with opening an issue for this and linking to it, though adding some way for the RoomKeyImportResult to trigger a retry_event_decryption() call shouldn't be terribly complex either.
No description provided.