Sliding sync: Clear the device list cache when the connection is reset.

[erikjohnston]

There is a change in behaviour with device lists between the sliding sync proxy and simplified sliding sync. When the client "resets" the encryption sync loop (i.e. sends a request with no since token):

• The proxy returns all device lists updates since the last request from the device that asked for device lists (this works similarly to to-device message handling).
• Synapse returns no device lists updates, as it only returns changes since the provided token (which is null). This is in line with sync v2.

The effect of the above is that the rust sdk can easily miss device list updates that happen between the previous encryption sync request and sending an initial encryption sync request, when using SSS. Given the encryption loop "resets" relatively frequently (on one account it happened ~8 times in 12 hours), this will cause quite a few UTDs.

The Rust SDK should therefore ensure whenever the connection is reset the device list cache is cleared. To mitigate the performance impact of this change, the SDK may want to try and reduce the number of times it proactively resets the connection (I think this happens whenever a request fails).

The alternative would be to change how Synapse behaves to match the proxy. However, this would be quite a big undertaking with unknown costs (device list management is already incredibly expensive in Synapse, converting it to track what updates we have sent to each device would likely make it even worse).

[kegsay]

The major changes here afaict are:

• The rust SDK needs to persist the pos value for the encryption loop, similar to how it persists the since value for the to-device extension today.
• The rust SDK needs to hand this pos value off to the NSE push process to ensure that it doesn't sync without a pos value.

If either of these things goes wrong, we'll sync without the correct pos and lose device list updates. The whole thing feels kinda brittle to me but it is what it is 😞

[erikjohnston]

Given there are already locks to ensure that the encryption loop doesn't run at the same time as the other process, and correctly persists the received updates, I'm surprised it doesn't reuse the pos.

The major changes here afaict are

Those things won't actually fix this bug though, as you'd still need to invalidate the device list cache if you reset the connection. Those changes help by reducing the number of times the SDK does do that.

A few other things to note:

• The e2ee extension isn't needed to decrypt messages, so we could move the e2ee extension out of the current encryption loop and have it just run on the main process.
• Doing a one-off encryption sync with no since token will return to-device messages that were already received. Not sure if that matters much.
• Doing an encryption sync without setting a since will invalidate the pos on the main process, meaning that the server will respond with an M_UNKNOWN_POS if the old pos was used again (though doesn't look like we do that).

---

In general I'd reiterate that the general architecture of sync (both sliding and v2) is to assume the client is starting from a clean slate if it receives an initial sync. Often this doesn't matter, but the SDK does have to be a little bit careful, e.g. (slightly different but still) the SDK does not clear the cached required_state when it receives a room entry with initial=true and instead treats the required_state as a delta.