In D12986#367417, @ashoat wrote:

Great work on this!! You made the diff stack really easy to review

In D12914#366648, @ashoat wrote:

In D12914#366501, @ashoat wrote:

Ok, let's add it for consistency, but it is still confusing. @ashoat do you know why MutableThickRawThreadInfo includes community?

This was my mistake. Would it be easy to remove at this point? We might consider a follow-up task for this if not.

This comment wasn't responded to. It looks like this diff was landing with support for the community column, which isn't ideal, but probably won't be an issue if nobody calls it with community set.

Still, at the very least I'd like to see a follow-up task created for removing community from ThickRawThreadInfo (and any related types).

Run ops in parallel

Rename. Run ops in parallel.

Set the timestamp

Fix result check

Rebase

Rename

Capitalize an acronym

Revert readonly

Bump the version

Bump the version

Rebase

In D12921#366498, @ashoat wrote:

Discussed something similar for updating unread status here.

1. Updating the replies count happens through an update. If we extract the logic from the specs, we would need to inspect returned updates and modify or create a new one with the replies count update.

This is true, but we could implement a utility that handles it. I don't think it would be that complicated.

2. Messages can be returned both in rawMessageInfos and as a part of some updateInfos.

Perhaps mergeUpdatesWithMessageInfos could be helpful here?

Each of these could be complicated, and it seems they mostly move complexity from one place to another.

Ultimately my goal would be to unify the complexity in one place, so we can mitigate the risk of the programmer forgetting to handle it in a specific case, and so we could reduce code duplication.

In D12881#366497, @ashoat wrote:

In D12881#366279, @tomek wrote:

In D12881#366124, @inka wrote:

Should we set the unread status?

Yes, you're right!

I wonder if it would be better to handle this as a "side effect" of the main processDMOperation. We could take a similar approach to updating the replies count.

We would need to check all of the rawMessageInfos, as well as any messages in the updateInfos, to see if any new messages are introduced that aren't from the viewer. This could potentially be done in useProcessDMOperation. Potentially mergeUpdatesWithMessageInfos could be helpful for extracting the messages from the updates.

@tomek, what do you think? A unified approach would mitigate the risk of the programmer forgetting to handle it in a specific case, and it would reduce code duplication.

Delete unnecessary check

In D12835#366494, @ashoat wrote:

I wonder if the AddMembers spec should be split into two: one for adding the viewer, and one for adding somebody else

Then when somebody adds a member, they'll send the first type to all of the added users' devices, and the second type to all of the existing users' devices

What do you think?