Thanks!

Merge imports

Simplify the logic and add a comment

Move the function

Extract a constant

Remove the method from DatabaseQueryExecutor

Make the method private

Format

Update names

Fix fetching the last message

We don't stop after fetching the first batch. Instead, we're fetching all the batches one by one immediately.

This is caused by the fact that fetching from the DB is too fast. We probably have an existing bug, that wasn't caught, because fetching from keyservers is a lot slower.

Overall it looks ok, but there are a couple of things that should be fixed, so I'm requesting changes.

It is a really good idea to split this diff because it does a couple of unrelated things. Especially, the part about sending notifs requires some discussion and changes, while all the other parts could be accepted.

Make comments consistent

Rebase

Rebase

Extract thick thread types

Extract thick thread types

In D13085#371052, @ashoat wrote:

I don't love that we have two separate mechanisms for this. alertStore's purpose is to record when we show various alerts, and help us control how often we show them based on when they're been shown before. That's basically this use case as well. If there are some differences, I would think it would be better to extend alertStore to do what we want here (eg. use useOnFirstLaunchEffect or persist in a similar fashion) rather than building a separate mechanism.

I'm going to resign as I'm heading to vacation starting tomorrow and it doesn't appear that we have the time to do things right here.

Rename

In D13057#370589, @ashoat wrote:

In D13057#370275, @tomek wrote:

In D13057#370009, @inka wrote:

One thing we could do here is add a separate update type for unread status. This way the logic from D13059 that needs getUpdatedThreadInfo would not be needed, and so getUpdatedThreadInfo would not be needed. But this might be too much work.

Yeah, I'm still not sure if it is a good idea. This change would greatly simplify this logic, but has some downsides: introducing a whole new update type would require implementing its spec, which contains e.g. keyserver db layer - and we don't need that, but skipping it would also be weird. If we introduce this new update type, we will need to answer a question as to why we don't introduce similar updates for other props of the thread info... and it seems like we should do that - introduce a new update info that allows updating any property of thread info in isolation. But that might take some time. I don't think it is worth doing now.

I'm confused about this discussion... don't we already have updateTypes.UPDATE_THREAD_READ_STATUS?

In D13064#370575, @ashoat wrote:

Ah – the answer to my question is "Because we're using layout animations, rather than animations driven by a SharedValue." While this approach likely works for the NUX project, I suspect it won't work for the more complicated cases we need to support as part of ENG-8149. It's unfortunate that the approach you've chosen means that your work won't be generalizable.

In D13085#370584, @ashoat wrote:

Requesting changes because it seems like alertStore can be used here, and I'd rather avoid reimplementing logic when we can share it instead