This diff fixes messages appearing unread by adding a timestamp check when getting new messages.
https://linear.app/comm/issue/ENG-9727/thick-threads-appearing-unread
Details
Details
- User A logs to web and mobile
- User B logs to web
- User's A mobile is in background
- User B sends DM to A
- User A reads the message on web
- User A brings mobile back to foreground. Verify the last message is not unread.
- Repeat a few times
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- graszka22/ENG-9727
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
When @kamil was working on D13576, we had a discussion about this logic.
What is our thinking about this now?
We're mitigating the risk of messages being delivered in the wrong order (I think so):
User A receives a message from user B, then reads the message and we have a timestamp T1. Then receive a message from user C with a timestamp lower than T1 (this is something really possible to happen in the P2P world), we want to bump the unread status anyway. The philosophy behind that was that it's better to have unread even if we saw all the messages, than not having unread when new messages are there.
Separately, setting @tomek as blocking as he originally decided on this logic.
Comment Actions
What is our thinking about this now?
Currently, there's no single best solution. Even when we show a thread as unread, the delivered message could be quite old, and a user isn't able to easily tell which message is the new one. So both solutions are far from ideal. We could consider moving read status to a message level, but that would be a separate project.