We're assuming the oldest possible update time.

My proposition will break in case the equality comes from the if above being run - we won't add the user to members. But we should still handle the case where this timestamp collision is a result of two separate requests

Created https://linear.app/comm/issue/ENG-9159/thick-threads-timestamps-conflict-resolution to track the timestamps conflicts resolution.

Why do we bump the timestamp even if we continue on line 100 below?

If no changes end up being applied, is there a way we can skip this update, instead of propagating an empty update?

It is to handle the following scenario:

1. We receive an operation about a user being added at time T
2. We don't receive an operation about the user leaving the thread at T+1
3. We receive an operation about the user being added at T+2

We want to keep the user in the membership table, but we should update the timestamp so that when we receive the operation from T+1 we don't remove the user.

Obviously, there is, but the case where no updates were made is a relly unlikely edge case, and don't think is worth introducing. If you feel strongly, I can add that (and review all the specs to check whether we can skip updates also there). Created https://linear.app/comm/issue/ENG-9232/consider-skipping-creating-updates-when-there-are-no-changes-to-a to track.

Thanks for explaining!

Appreciate the explanation. I don't feel strongly, and didn't have the context that it's unlikely. I don't feel strongly, so I'll go ahead and cancel the task you created – sorry for the churn!