Can't we handle this in useProcessDMOperation just like canBeProcessed?

This is a little messy. Curious about @inka's suggestion. If there's some specific information needed from processDMOperation, I'd consider returning that explicitly, and handling it from the caller – it would improve readability, and simplify the logic in the specs

Agree that it would be a lot better to extract the logic from the specs. I'm going to think about it more but at this point, it seems hard because:

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.
2. Messages can be returned both in rawMessageInfos and as a part of some updateInfos.

There are some possible ideas, e.g.

1. We can consider returning something different than rawMessageInfos and updateInfos from the specs, so that it's easier to know if the count should be updated.
2. We can start updating the count using a separate action and return a new count next to rawMessageInfos and updateInfos.
3. We can modify reducers to compute the replies count based on new messages automatically.

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

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

Makes sense! Created https://linear.app/comm/issue/ENG-8930/unify-the-approach-to-replies-count-and-unread-status-updates to track.