Page MenuHomePhabricator

[server] Don't unset TRUNCATED if threadCursor is null
ClosedPublic

Authored by ashoat on Mar 11 2022, 11:39 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Dec 4, 3:32 AM
Unknown Object (File)
Nov 8 2024, 10:39 PM
Unknown Object (File)
Nov 8 2024, 8:08 PM
Unknown Object (File)
Nov 2 2024, 9:53 AM
Unknown Object (File)
Nov 2 2024, 8:31 AM
Unknown Object (File)
Oct 19 2024, 11:08 PM
Unknown Object (File)
Oct 19 2024, 10:43 PM
Unknown Object (File)
Oct 19 2024, 7:47 PM

Details

Summary

While working on the previous diff, I noticed an issue here. Before D3351/D3352, we didn't actually use fetchMostRecentMessages anywhere in the codebase, which meant that we never set a threadCursor to null.

Now that we're actually using null threadCursors, we need to consider how they're handled here. In this particular case, we have some logic to unset TRUNCATED on the assumption that the result set is contiguous.

I don't think we can or should assume that for fetchMostRecentMessages. Instead, I think we should set TRUNCATED so that the MessageStore for that thread gets cleared, since we can't guarantee that whatever is currently in the MessageStore will be contiguous with the most recent messages.

Test Plan
  1. I tested different values of defaultMaxMessageAge such that some threads would return fewer than defaultNumberPerThread, and some threads would return 0
  2. I tested threads that needed a fetchMostRecentMessages, and threads that needed multiple fetchMessagesBeforeCursor to get to the start
  3. I made sure all threads loaded all the way to the start of a thread if I kept scrolling

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage