Page MenuHomePhabricator

[lib] Add timestamp check when flipping unread status
ClosedPublic

Authored by angelika on Oct 22 2024, 5:28 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Dec 16, 2:23 AM
Unknown Object (File)
Tue, Dec 10, 5:50 PM
Unknown Object (File)
Wed, Dec 4, 11:50 AM
Unknown Object (File)
Wed, Dec 4, 11:50 AM
Unknown Object (File)
Wed, Dec 4, 11:49 AM
Unknown Object (File)
Wed, Dec 4, 11:33 AM
Unknown Object (File)
Mon, Nov 25, 9:20 AM
Unknown Object (File)
Mon, Nov 25, 6:17 AM
Subscribers

Details

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
Lint
Lint Not Applicable
Unit
Tests Not Applicable

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.Oct 23 2024, 3:19 AM