-
-
Notifications
You must be signed in to change notification settings - Fork 605
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
Comments
The problem here appears to be as follows:
The code in |
I think the proposed fix is to update the code in |
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. |
Answer: yes, we call
Conclusion: just don't do this (reset unread status) for synthetic receipts. |
Fixes #3684 and there are lots more details about why we chose this solution in that issue.
Fixes #3684 and there are lots more details about why we chose this solution in that issue.
Suppose:
/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.The text was updated successfully, but these errors were encountered: