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.

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.

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 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?

Yes, we have. But this discussion was about introducing a new update for the replies count - which was the goal of this whole diff stack.

I think this comes from the comment

One thing we could do here is add a separate update type for unread status.

Which contains a mistake. The new update, we were considering, should be for the replies count.

Thanks for explaining!