Page MenuHomePhabricator

[lib] Add numMessagesToFetch param to useFetchMessages
ClosedPublic

Authored by ashoat on Feb 25 2025, 12:20 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Apr 16, 3:46 AM
Unknown Object (File)
Sun, Apr 6, 7:30 AM
Unknown Object (File)
Sun, Apr 6, 1:00 AM
Unknown Object (File)
Sat, Apr 5, 9:05 PM
Unknown Object (File)
Sat, Apr 5, 12:37 PM
Unknown Object (File)
Wed, Apr 2, 3:20 AM
Unknown Object (File)
Mar 21 2025, 5:57 AM
Unknown Object (File)
Mar 14 2025, 1:20 PM
Subscribers
None

Details

Summary

I observed an issue where the message fetch here ends up triggered MessageStorePruner. Normally, a message fetch can only happen when the viewer is looking at a thread, which results in lastNavigatedTo being bumped, which prevents MessageStorePruner from immediately triggering. But in the linked code the message fetch doesn't happen when the viewer is looking at a thread.

We could introduce a new action here to also bump lastNavigatedTo, but I don't think it's needed... if we can't get an acceptable MessagePreview within the first defaultNumberPerThread (unlikely), it's probably fine to just default to mostRecentMessageInfo, even though it's failing the showInMessagePreview check.

This diff simply introduces a numMessagesToFetch param to useFetchMessages, which will allow us to fetch just underneath the number we need to avoid MessageStorePruner being triggered. The next diff will adjust the code linked above.

Depends on D14399

Test Plan

I used this patch that adds a bunch of logs and ran a Release build of the iOS app pointed at production on my physical iOS device.

In combination with the next diff, I confirmed that the logs of message prune actions were gone.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable