SSS: Persist the `pos` token so that it gets reused across app restarts
Should only be done after https://github.com/matrix-org/matrix-rust-sdk/issues/3935
This is so that after restart we don't do an initial sync, which pulls in all the room data again (causing load on the server, and also on the client and bandwidth).
(cc. @Hywan)
Thanks for creating the issue.
For reference: we tried in the past and ran into sync issues (something something multiple processes on iOS because of NSE process? can't recall the details), so had to emergency-disable it: https://github.com/matrix-org/matrix-rust-sdk/blob/a737421875a1f1f81ac416dd4576fbd776d5d307/crates/matrix-sdk-ui/src/encryption_sync_service.rs#L106
PR disabling it: https://github.com/matrix-org/matrix-rust-sdk/pull/2525
Oh my goodness :) After adding some logs in synapse I can confirm this is why the sync after an app restart is slow on Android.
Could we enable share_pos on the room list here without triggering cross processes dragons ?
If not can we make this an option so that we can store the pos at least on Android in the meantime ?
Could we enable
share_poson the room list here without triggering cross processes dragons ?
I don't know if it's enough to not trigger dragons but it seems like the NotificationClient does not initialize the room list service in multiprocesses mode.
The PR I've listed above disabled it for the encryption sync; we could enable it for the state sync, since the notification client uses a different connection id than the main app.
FYI I've been running a modified version since a couple of days with share_pos on the room-list sliding sync instance and it's a night and day difference.
As expected no trouble on my Android, but I don't have the means to test iOS.
We are disabling share_pos() because it creates slowness (see #4244). Reopening this issue.
Can we close this issue?
Yep, let's consider it done after the latest attempt that appears to be quite successful in production builds.
Thanks for the triaging!