Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Notification counts may be incorrectly reset by sent messages #3684

Closed
richvdh opened this issue Aug 29, 2023 · 4 comments · Fixed by #3706
Closed

Notification counts may be incorrectly reset by sent messages #3684

richvdh opened this issue Aug 29, 2023 · 4 comments · Fixed by #3706
Labels

Comments

@richvdh
Copy link
Member

richvdh commented Aug 29, 2023

Suppose:

  • You invite Bob to a room. Bob immediately joins and sends a message.
  • /sync is slow for whatever reason, and Bob's message is returned in the /sync response as the remote echo of your invite event.

In that scenario, Room.getUnreadNotificationCount() should return 1. However, it currently returns 0. This causes the client to show the room as fully read, whereas in fact there are unread messages.

@richvdh
Copy link
Member Author

richvdh commented Aug 29, 2023

The problem here appears to be as follows:

The code in Room.addReceipt was added in #3139, and it replaced a previous hack in matrix-react-sdk (https://github.com/matrix-org/matrix-react-sdk/blob/v3.72.0/src/components/structures/TimelinePanel.tsx#L1090-L1103). It is needed to mark a room as read quickly when we send a read receipt, without waiting for the remote echo of that receipt (in contrast what the comment says).

@richvdh
Copy link
Member Author

richvdh commented Sep 6, 2023

I think the proposed fix is to update the code in Room.addReceipt (https://github.com/matrix-org/matrix-js-sdk/blob/v28.0.0/src/models/room.ts#L2944-L2950) to ignore synthetic receipts.

@andybalaam
Copy link
Contributor

OK, I had some further discussion with @richvdh over DM and want to try and summarise here:

I was getting confused because I was thinking the correct time for this code to run was when we sent a message, but the correct time is when we send a receipt (because the user read something).

So, if we ignore synthetic receipts, we avoid times when we either send events or receive events via sync. In both of these cases we don't need to modify the unread count.

The last question for me is: what happens when we receive receipts over sync? Do we need to avoid running this logic at that time? We think the answer is no, because it will run after the messages have been processed, so the logic checking for the last event will be work as intended.

@andybalaam
Copy link
Contributor

Answer: yes, we call Room.addEphemeralEvents during sync (src/sync.ts:1460) after we've called injectRoomEvents.

addEphemeralEvents does call addReceipt, but it is already late enough that the logic in there about checking for the last event in the room is OK.

Conclusion: just don't do this (reset unread status) for synthetic receipts.

andybalaam added a commit that referenced this issue Sep 6, 2023
Fixes #3684
and there are lots more details about why we chose this solution in that
issue.
github-merge-queue bot pushed a commit that referenced this issue Sep 7, 2023
Fixes #3684
and there are lots more details about why we chose this solution in that
issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants