Page MenuHomePhabricator

[keyserver] Introduce latestMessageForUnreadCheck to LatestMessageInfo
ClosedPublic

Authored by ashoat on Feb 11 2025, 12:08 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Mar 22, 9:00 AM
Unknown Object (File)
Sat, Mar 22, 8:44 AM
Unknown Object (File)
Mon, Mar 17, 9:26 AM
Unknown Object (File)
Sun, Mar 16, 3:26 PM
Unknown Object (File)
Fri, Mar 14, 5:29 AM
Unknown Object (File)
Fri, Mar 14, 5:12 AM
Unknown Object (File)
Fri, Mar 14, 4:45 AM
Unknown Object (File)
Fri, Mar 14, 4:26 AM
Subscribers
None

Details

Summary

This diff is a no-op; it simply moves the setting of this value "upstream" a bit. Later diffs will change the actual value.

Depends on D14332

Test Plan

Tested in combination with later diffs, to confirm that it's possible for some message types to not set a thread to unread

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

tomek added inline comments.
keyserver/src/creators/message-creator.js
604–607

Why do we need this change?

This revision is now accepted and ready to land.Feb 11 2025, 5:47 AM
keyserver/src/creators/message-creator.js
604–607

A thread should only be marked as unread if:

  1. latestReadMessage is not set. In general, we only bump last_message_for_unread_check (formerly last_message) and don't bump last_read_message, but there are two exceptions: the member's self-authored messages, and messages in threads are currently in-focus by the member (see lines 557-558)
  2. The new check, latestMessageForUnreadCheck. Previously we would always bump last_message, but now for last_message_for_unread_check, in certain cases we will not bump it (defined in later diffs inside message specs).

You might ask why we needed a new mechanism here. Could we have handled not setting certain threads to unread by simply updating last_message? The reason we couldn't do this was because in the case of a thread that is currently unread, we would end up making it unread if we bumped last_read_message alongside last_message. This behavior is okay for the member's self-authored messages (sending a message always sets that thread to read for the author) and threads that are currently in-focus (we always want to set them to be read), but it's not okay for the new feature.

We could consider replacing the old mechanism with the new one, but I decided to avoid that to keep scope limited.

keyserver/src/creators/message-creator.js
604–607

Correction on this part:

Could we have handled not setting certain threads to unread by simply updating last_message? The reason we couldn't do this was because in the case of a thread that is currently unread, we would end up making it unread if we bumped last_read_message alongside last_message.

Should have been:

Could we have handled not setting certain threads to unread by simply updating last_read_message? The reason we couldn't do this was because in the case of a thread that is currently unread, we would end up making it read if we bumped last_read_message alongside last_message.