This is inconsistent with the previous behavior. When the thread isn't in the store, and its ID isn't pending we were assuming it isn't thick - which corresponds to messagesStoredOnServer === true. I don't think such a case should happen, but even if it happens, we should proceed with a more conservative approach - avoiding saving startReached to avoid a case where we can't fetch messages from the local DB. If the thread is indeed thick - nothing wrong happens. If it is thin - the state should be fixed when we finally receive the thread.

this is just a question for my understanding: what does it mean for a thread to "be watched" and why does it matter here if thread's messages are stored on server?

Probably I misunderstood something but:

• if thread isn't in the store and its id isn't pending
• then now messagesStoredOnServer is false (ok)
• then we have this if:

messagesStoredOnServer
                ? thread
                : {
                    ...thread,
                    startReached:
                      thread.messageIDs.length < defaultNumberPerThread,
                  },

• so if messagesStoredOnServer is false then we save startReached?
• but you just said in the comment that we avoid saving it in this case?

even if it happens, we should proceed with a more conservative approach - avoiding saving startReached

Watching a thread has a couple of consequences, but to simplify it, it determines if we should get and keep the new messages. For example, the currently open thread is watched.

In this case, watching a thread determines that we won't discard any messages received by it. If messages are stored on a server, we can ask it later to resend messages if we need them. If the messages aren't on a server, there's no way of retrieving them after they are discarded.

Setting the value

startReached:
                      thread.messageIDs.length < defaultNumberPerThread

means that we won't set startReached = true when thread.messageIDs.length >= defaultNumberPerThread. Setting it to true means that we won't attempt fetching more messages when a user scrolls up. Initially, we fetch defaultNumberPerThread messages. So if startReached = true and there are more than defaultNumberPerThread messages, we won't fetch more messages. We want to avoid that by setting the flag to true only when there are less than defaultNumberPerThread messages - a more conservative approach.

One missing piece might be that thread also has a startReached computed, but without the adjustment based on defaultNumberPerThread.