element-x-ios
element-x-ios copied to clipboard
element-hq
No spinner while catching up on to-device msgs
Steps to reproduce
- Launch app for first time in a few weeks
- UISIs, UISIs, everywhere
- Over the next minute or so, they slowly decrypt.
- No spinner at all to let you know that the app is working through a massive todevice encryption backlog.
Outcome
What did you expect?
Some kind of spinner, if we're still frantically syncing data which is needed to decrypt history. This probably shouldn't be the main sync spinner, though, given the app is otherwise usable (at least for reading msgs). Could perhaps do spinner per UISI msg? "Getting keys
Alternatively, should SS perhaps just have a flag in its responses to let the client know when it's churned through the backlog, so we know when to display an actual UTD rather than "Getting keys"?
What happened instead?
No spinner, much flakiness, much sad.
Your phone model
No response
Operating system version
No response
Application version
276
Homeserver
No response
Will you send logs?
Yes
Worse, this means that self-verification will get completely stuck behind the to-device queue, and fail in weird ways (claiming you cancelled it when it actually timed out), and then fail again immediately if you try again, but work the 3rd time. Without a spinner, you expect verification to work.
So clients can apply a heuristic today to see if there are more to-device messages. The client can set a limit on how many events they want, and if the response contains that many events then you're still catching up. When it contains < limit then you're good to go. Having a caught_up bool only really helps remove the spinner fractionally earlier when you have a multiple of $limit events afaict.
FWIW, on the Kotlin SDK, as long as they are toDevice Events in the sync v2 response, the sync request timeout is set to 0, to ensure that the next response will return as soon as possible. Similar workarounds have been implemented on other clients.
Related to https://github.com/matrix-org/synapse/issues/11457.
Disclaimer: my comment is maybe not helping, I do not really know how the sliding sync work regarding toDevice Events.
The sync indicator/spinner displayed on the app right now is provided by the RoomListService API.
If you want another sync indicator/spinner for to-device events, it must be provided by the EncryptionSync API. It's really not complex to implement in the SDK, but it needs product and design decisions before that.
This continues to be painful - i just turned on my EXA for the first time in a few months, and all the history is UTD, presumably because it's slowly crawling through a huge backlog on to-device msgs... but with no visible indication that it's still catching up.