matrix-org / matrix-org/matrix-rust-sdk
recovery: event handlers ran a request in the same task, slowing down the task's progress
- Dominant language
- Rust
- Stars
- 2.3k
- Forks
- 500
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 106
Description
In these [two event handlers](https://github.com/matrix-org/matrix-rust-sdk/blob/40ba98b95e9c9816d392dd0a2b99e68549633108/crates/matrix-sdk/src/encryption/recovery/mod.rs#L502-L510) added automatically when enabling key recovery, we start a [network request](https://github.com/matrix-org/matrix-rust-sdk/blob/40ba98b95e9c9816d392dd0a2b99e68549633108/crates/matrix-sdk/src/encryption/secret_storage/mod.rs#L273) to get the latest version of the state event. This slows down progress on the sync task, which can be an issue if the server is also busy doing other things, or very slow to respond.
Possible fixes:
- run the request in a background task (make sure there's only one, if there's one active consider cancelling it and restarting it, etc.)
- get the event from the store; apparently not the best, because the sliding sync proxy [can return stale state account data events](https://github.com/matrix-org/sliding-sync/issues/189).
Contributor guide
Research direction
Start by reading the two recovery event handlers in crates/matrix-sdk/src/encryption/recovery/mod.rs around lines 502-510 and the state-event request in crates/matrix-sdk/src/encryption/secret_storage/mod.rs around line 273. Trace how the request runs during sync, then determine the intended background-task lifecycle, including duplicate or restarted requests. Done means recovery no longer delays sync progress while still obtaining current state data.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100