Hypothetical situation to consider: user is active in many threads but never navigates to any

1. The first time nextMessagePruneTimeSelector computes nextTime it'll be 21600000 (6 hours from epoch)
2. User receives 500 messages in eg Comm Supporters, but never navigates to any threads
3. nextMessagePruneTimeSelector will still compute nextTime as 21600000, because the time hasn't changed MessageStorePruner won't initiate pruning

In this scenario the user would have messages accumulating, but none would be pruned if the user never navigates to a thread.

This is less of a problem an issue with the previous approach because lastPruned gets set to Date.now() as part of newThread. However, the following is still possible:

User is in two threads:

Thread A

• 5 messages
• never navigated to
• never pruned, lastPruned set to hour 6 (when thread added to redux)

Thread B

• 5 messages
• never navigated to

never pruned, lastPruned set to hour 12 (when thread added to redux)

At hour 14:

1. User receives one message in Thread A
2. nextMessagePruneTimeSelector gets recalculated because state.messageStore.threads changes
3. threadPruneTime is calculated as hour 18 (Thread B lastPruned + 6 hours)

At hour 100

1. User receives 500 messages in Thread A
2. nextMessagePruneTimeSelector gets recalculated because state.messageStore.threads changes
3. threadPruneTime is calculated as hour 18 (Thread B lastPruned + 6 hours)
4. threadPruneTime is the same as it was at hour 14, so the useEffect in MessageStorePruner isn't "triggered," and nothing is pruned.

One improvement could be to set lastPruned to Date.now() in reduceThreadActivity for updateThreadLastNavigatedActionType action if lastPruned is unset (eg lastNavigatedTo is being set for the first time).

However, we still have the case (with our lazy loading of threadActivityStore approach) that if a user never navigates to any threads ever, and receives a ton of messages in a never-navigated-to thread: those messages will never be pruned.

If the goal of message pruning is simply to optimize and manage messages as best as possible under "normal conditions," then this is probably adequate. But, if we need a guaranteed method to ensure only a certain number of messages remain in the store for a certain period of time, we might need to consider a different approach.

Personally, I think setting lastPruned to Date.now() in reduceThreadActivity for updateThreadLastNavigatedActionType should be adequate.

If we want to match existing behavior, we could also "eagerly" set lastPruned for all threads in ThreadStore by looking at ThreadDeletionUpdateInfo | ThreadJoinUpdateInfos payloads in reduceThreadActivity.