Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Bug]: Fix new omemo device alert #1313

Open
tmolitor-stud-tu opened this issue Nov 23, 2024 · 0 comments
Open

[Bug]: Fix new omemo device alert #1313

tmolitor-stud-tu opened this issue Nov 23, 2024 · 0 comments
Labels
🦸 Help wanted If you are motivated, this is a good start!

Comments

@tmolitor-stud-tu
Copy link
Member

tmolitor-stud-tu commented Nov 23, 2024 •
edited
Loading

We should not call MLOMEMO postOMEMOMessageForUser:withMessage: from MLOMEMO processOMEMODevices:from: because there could be subsequent devicelist updates still in our receive queue.
The most common case could be a device added, removed by an update from another device and then added again by the first device.

The proper solution would be to record all devicelist changes since the last call to MLOMEMO handleHasLoggedIn: and "deduplicate" them when MLOMEMO handleCatchupDone: gets called. Then call MLOMEMO postOMEMOMessageForUser:withMessage: with that "deduplicated" list.

This solution is somewhat similar to our solution of queuing session repairs and key transport elements until catchup done.
@tmolitor-stud-tu tmolitor-stud-tu added the 🦸 Help wanted If you are motivated, this is a good start! label Nov 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
🦸 Help wanted If you are motivated, this is a good start!
Projects
Monal Team
Status: No status
Milestone
No milestone
Development

No branches or pull requests
1 participant
@tmolitor-stud-tu