fix(threading): Handle threads with duplicate send times #10176
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Christoph Wurst <[email protected]>
ChristophWurst
added
bug
3. to review
feature:threading
papercut
hamza221
approved these changes
Sep 19, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.