Closed ara4n closed 2 months ago
Build 638 doing it wrong: https://github.com/element-hq/element-x-ios-rageshakes/issues/1941 Build 637 doing it right: https://github.com/element-hq/element-x-ios-rageshakes/issues/1942
For what it's worth, the SDK changelog (based on commit SHAs) is the following, which doesn't seem to include any performance-sensitive changes, or any change related to the room list itself:
52fa00e47 sdk: remove `Error::InconsistentState` as it was unused
17d18321f send queue: mark `ConcurrentRequestFailed` as recoverable
374da7674 crypto: Remove assert_matches2 from regular dependencies
38a18c3c8 feat(ffi): add Element specific well known struct and a way to deserialize it from external clients
70fddc0e1 feat(ffi): expose method for reading the server name part of the current user's identifier.
84796ab32 feat(ffi): expose method for sending generic GET requests through the SDK's inner HTTP client.
6464d2181 crypto: Storage changes for keeping sender data with InboundGroupSessions (#3556)
cb4c57523 Reshare Megolm session after the other party unwedges (#3604)
i may also be seeing weirdness in 636 (on macOS at least). although 637 on iOS seems ok :/
update - 637 on iOS is also intermittently being incredibly slow
Probably related to is_encrypted
field we are going to remove
hmm. has this hit EXI Nightly yet? should the bug be closed once it hits the app and is confirmed closed, rather than at the SDK level? I'm still seeing sluggish roomlist filtering on bad connectivity on EXI 642 (i.e. with local list sorting), but from a QA perspective I don't know if this is a new bug or not. Reopening for now...
confirmed fixed in 644
Steps to reproduce
Outcome
What did you expect?
Instant room list filtering, even on big accounts like mine.
What happened instead?
10s to filter the room list, with loads of false results.
Your phone model
No response
Operating system version
No response
Application version
638
Homeserver
No response
Will you send logs?
Yes