fix(threading): Handle threads with duplicate send times #10176
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A thread with two messages with identical sent_at result in a problematic situation. The backend will return both messages when listing the inbox. The front-end will de-duplicate and only show one of the two. At every browser-server sync, the picked duplicate will be replaced by the other message. At the next sync they are replaced again. Etc. This causes endless notifications.
I ran into this with a thread for an outgoing message that was replied to by the mail server. This seems to be the rare case where two messages in a thread have an identical send time because they were processed in the same second.
How to test
main: the two messages toggle.
here: only one of the messages is loaded and never replaced.
Note: I can't come up with a good way to find out which of the messages with identical send time are "newer". I just sort them by message id. It's a bit "random" semantically but keeps the sorting stable.