Page MenuHomePhabricator

[keyserver] Consider all new messages in determineLatestMessagesPerThread
ClosedPublic

Authored by ashoat on Feb 11 2025, 12:07 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Mar 26, 7:48 AM
Unknown Object (File)
Thu, Mar 20, 10:26 PM
Unknown Object (File)
Tue, Mar 11, 4:13 PM
Unknown Object (File)
Tue, Mar 11, 3:42 PM
Unknown Object (File)
Sat, Mar 1, 12:02 PM
Unknown Object (File)
Feb 25 2025, 4:51 PM
Unknown Object (File)
Feb 22 2025, 9:20 PM
Unknown Object (File)
Feb 22 2025, 9:20 PM
Subscribers
None

Details

Summary

determineLatestMessagesPerThread currently has a subtle bug due to the fact that it only considers the last message index. (It iterates through all of them, but only the last one matters because it overwrites the results from earlier ones.)

latestMessage is getting set correctly in all cases, but the bug is that latestReadMessage can be wrong in some cases. In particular, if the most recent message doesn't set latestReadMessage, but an earlier one does, then the earlier one will be ignored and latestReadMessage will not be set.

This is a pretty extreme edge case because it only applies in the case that we have messages from different authors in the createMessages call, which I don't believe happens at any current callsites. But it still makes sense to fix the bug, and the issue becomes more relevant in future diffs where we introduce code to set latestMessageForUnreadCheck as well.

Depends on D14331

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