Repository navigation
A room with only private read receipt keeps being marked as unread. #23027
Description
Steps to reproduce
- Turn on private RRs
- Get DMed by a user
- Answer the DM
- Send some messages in the DM
- Observe that the DM subsequently gets incorrectly flagged as unread (presumably because there is no RM or RR in the room at all, only a private RR?)
(appaprently the room where this was happening (!iKaweBjcahmPGZlkqW:thirdroom.dev) had a prefixed private RR in it: $OyTvOe_8mTpK_f_Lf9cLR63ZdyOvIGvCCQrGqBokXxg )
Outcome
What did you expect?
Random DMs shouldn't keep appearing as unread.
Operating system
No response
Application version
nightly
How did you install the app?
nightly
Homeserver
matrix.org
Will you send logs?
No
Activity
turt2live commentedon Aug 8, 2022
With all the data we have on this, I think it's a long-standing issue to do with Element "randomly" (deterministic symptoms not yet discovered) deciding that rooms are suddenly unread during startup. Usually this happens to larger rooms, but can happen to DMs as well.
I don't think this is related to recent Synapse work or hidden read receipts, at least given the problem description.
SimonBrandner commentedon Aug 11, 2022
It turns out this is an RR issue after all: I've just reproduced it by accident in my DM with Dave. The
Room::getEventReadUpTo()method fails under certain conditions: if we don't have RRs of all types, we fallback to using timestamps for the comparison, the problem then is that the ts comparison algorithm doesn't take into account the stable private read receipt not being defined, so it fails and we fallback again to picking by hand, this means the unstable private RR is chosen because it tends to have precednce even if there actually is a new RR ofm.readtype.This can now be considered a release blocker though a fairly simple one to fix and test
Merge tag 'v19.3.0' into sc
Merge tag 'v19.4.0' into sc