This is probably invalid (doesn't cause any bugs, but might be inefficient). I'll review if we should use a different value.

This is an interesting approach. It seems like if I were to look at SQLite for a thick thread containing more than defaultNumberPerThread messages, I would see startReached = false.

This is a bit confusing because the list of messages in SQLite is "complete" in the sense that all messages that the client can view are stored there. So I guess I would expect startReached = true for all thick threads in SQLite.

Did you consider any alternatives? For instance, I wonder if this hack could be applied at read time instead of at write time.

I was considering the alternative where we modify the value at the read time, but it has a couple of issues:

1. If all the thick threads had startReached = true then this flag would become completely useless
2. It might be confusing to save one value to the DB and then read some other - in the current approach we read what we save
3. The read query would become a bit complicated because reading threads would require counting messages

For me, both approaches make some sense but also could be confusing. The one from this diff is simpler to implement and less confusing to me.

Thanks for explaining!