SSS: read receipts are missing

[ara4n]

Steps to reproduce

1. send a bunch of messages in EX with SSS
2. feel upset that nobody is reading them
3. compare with EW, and see that people are reading them.
4. wonder why some RRs are present, but not recent updates

Outcome

What did you expect?

consistent RRs

What happened instead?

missing RRs

Your phone model

No response

Operating system version

No response

Application version

666

Homeserver

No response

Will you send logs?

No

[manuroe]

@erikjohnston is it implemented on the backend?

[erikjohnston]

It is implemented in SSS, and we should be sending down all live receipts. The only time this doesn't happen is if the room comes down with initial flag set, in which case we will only send down receipts that match events in the timeline (and EX sets the timeline limit to 1, so you'd only see receipts on the last message).

So long as the room is in the range (and it should be), then SSS should be sending down all new receipts.

[erikjohnston]

It does look like the code may be a bit buggy when it comes to rooms coming into the range (it looks like it won't send existing receipts). Though I'd still expect in the case of M sending a message that a) the room will be in range and stay in range, and b) therefore he should see all new receipts.

[erikjohnston]

I think this is exacerbated by the fact the Rust SDK will occasionally reduce its range to [0,19] again and then grow the ranges. However, it can take ages to grow the lists as the SDK sets a timeout and so if there is nothing new in the update range the server will block waiting for updates.

[erikjohnston]

The server should now be correctly sending down read receipts, so hoping this is now fixed