Created a task describing the issue https://linear.app/comm/issue/ENG-5657/race-condition-when-sending-a-friend-request

N/A

Can we find a way of testing this code?

Measuring from before the parent diff, the incremental improvement is about 19%.

I guess there should be also a significant improvement in memory usage

What is the plan for the source?

I'm not an expert, but it seems reasonable and the test pan is thorough.

Simplify the code

In D9453#278162, @ashoat wrote:

Might be good for @tomek to meet with @atul to share more context about the update syncing specs. Or potentially could be a subject for a teamwide "office hours" this Wednesday (although not sure of the impact of blocking this diff until then... maybe could be a follow-up task?)

Handle an edge case when someone had a fresh store with the most recent code version and run a migration (userStore.inconsistencyReports wouldn't be present)

Clean up the code

This diff needs more work before it can be reviewed, but seems to fix (at least a part of) the performance issue.

Agree it is safer to handle all the actions that include the updates. But, at the same time, it is possible to introduce a new action that contains updates and forget to add it here. We probably should figure out a different approach and use it in all the places - e.g. instead of checking action.type, check if it has updateRedult.newUpdates (not sure if Flow will like it). - It isn't blocking this diff, but is a separate follow-up.

Disable chat mentioning

Shouldn't we also handle processUpdatesActionType action?

Use read only types in all the specs

In D9354#275224, @kamil wrote:

In D9354#275219, @kamil wrote:

LGTM, only one nit: you can probably replace Array<> with $ReadOnlyArray.

On the other hand, when you return the result we should allow the caller to do and modify the result, not sure what is better in this use case.

Use read only

Do we also plan to uncheck items in some cases? It looks like we're handling a case where an item wasn't created properly. I think that we also sometimes should look for a case where an item was deleted only partially (e.g. only a holder was left).

Use more functional approach

Make the approach more consistent

Fix reducer bug