Performed Kamil's test again (except the logs stuff) and the solution works correctly.

Check the timestamp before updating the status

In D13572#380889, @ashoat wrote:

Makes sense to me! Before landing, please:

1. Validate that there is a concrete issue being solved with this
2. Fill in the test plan

Fix the condition

Handle failed processing

In D13572#380812, @ashoat wrote:

There seem to be new risks from this approach, It's unclear to me what issue is being mitigated here. See my message from chat:

I'm not sure this has the same risk. it looks like DMOpsQueueHandler doesn't dequeue from a ref, and instead it dequeues from a useSelector result. doesn't that mean that newly-enqueued operations won't be processed by old effects?

Rename

In D13533#380315, @inka wrote:

Why do we expect to have multiple private chats, or multiple personal chats with one user? It's it impossible?

Rebase

In D13519#379786, @ashoat wrote:

Can you update the test plan to cover all of these scenarios?

1. Searching for a user on native with useUserSupportThickThread modified to return false for some users
2. Searching for a user on native without modifications to useUserSupportThickThread
3. Searching for a user on web with useUserSupportThickThread modified to return false for some users
4. Searching for a user on web without modifications to useUserSupportThickThread
5. Composing a thread on native with useUserSupportThickThread modified to return false for some users
6. Composing a thread on native without modifications to useUserSupportThickThread
7. Composing a thread on web with useUserSupportThickThread modified to return false for some users
8. Composing a thread on web without modifications to useUserSupportThickThread

Rebase

It's quite a large diff adding support for large notifs - I think it would be a lot easier to review it if it was split into multiple smaller ones. We don't have the time to split it, but overall the diff makes sense to me.

Shorthand

Rebase

Use Promise.all

Fix imports

Rebase

Check create sidebar message conflicts

Validate change thread settings operation

Check message ID conflict for all the operations

Update invariant message

Update comments and reorder functions

There are a lot of changes so requesting a review:

1. Get permissions from the parent even when the viewer is a member
2. Use permissions from the parent when setting the permissions for non-viewer members

Set permissions based on parent

Rebase

I don't have a strong opinion on this solution. We can keep it, or modify the type to be an array when the robotext creation flag is irrelevant, or we can even consider introducing specs for relationship actions where we define whether robotext messages could be created. But overall, I don't think it is beneficial to spend too much time on it, so even abandoning it makes sense because it is unlikely to cause any trouble in the future.

Inherit permissions from the parent