Page MenuHomePhabricator

[lib] Add timestamp check when flipping unread status
AcceptedPublic

Authored by angelika on Tue, Oct 22, 5:28 AM.
Tags
None
Referenced Files
F3051431: D13766.diff
Wed, Oct 23, 11:25 AM
F3047967: D13766.id45314.diff
Tue, Oct 22, 9:22 PM
F3043831: D13766.id45314.diff
Tue, Oct 22, 3:11 PM
Unknown Object (File)
Tue, Oct 22, 11:19 AM
Unknown Object (File)
Tue, Oct 22, 8:32 AM
Unknown Object (File)
Tue, Oct 22, 8:31 AM
Unknown Object (File)
Tue, Oct 22, 8:15 AM
F3036985: Screenshot 2024-10-22 at 8.58.37 AM.png
Tue, Oct 22, 6:02 AM
Subscribers

Details

Reviewers
kamil
tomek
Summary

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

Test Plan
  1. User A logs to web and mobile
  2. User B logs to web
  3. User's A mobile is in background
  4. User B sends DM to A
  5. User A reads the message on web
  6. User A brings mobile back to foreground. Verify the last message is not unread.
  7. Repeat a few times

Diff Detail

Repository
rCOMM Comm
Branch
graszka22/ENG-9727
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

When @kamil was working on D13576, we had a discussion about this logic.

Screenshot 2024-10-22 at 8.58.37 AM.png (1×2 px, 394 KB)

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.

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.

This revision is now accepted and ready to land.Wed, Oct 23, 3:19 AM