-
-
Notifications
You must be signed in to change notification settings - Fork 127
fix(groups): keep persisted group metadata in sync on membership change #761
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.
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
Changes from 1 commit
6f69026
c87a59a
8695ace
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1380,6 +1380,9 @@ async fn handle_group_notification(client: &Arc<Client>, node: Arc<OwnedNodeRef> | |
| .iter() | ||
| .map(|p| (&p.jid, p.phone_number.as_ref())), | ||
| ); | ||
| client | ||
| .persist_group_metadata(¬ification.group_jid, &info) | ||
| .await; | ||
|
Comment on lines
+1383
to
+1385
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
When a participant notification arrives after the in-memory group cache has expired (the default TTL is one hour) but a persisted metadata blob still exists, this block is skipped entirely, so the new Useful? React with 👍 / 👎. |
||
| group_cache | ||
| .insert(notification.group_jid.clone(), Arc::new(info)) | ||
| .await; | ||
|
|
@@ -1396,6 +1399,9 @@ async fn handle_group_notification(client: &Arc<Client>, node: Arc<OwnedNodeRef> | |
| if let Some(info) = group_cache.get(¬ification.group_jid).await { | ||
| let mut info = Arc::unwrap_or_clone(info); | ||
| info.remove_participants(&users); | ||
| client | ||
| .persist_group_metadata(¬ification.group_jid, &info) | ||
| .await; | ||
| group_cache | ||
| .insert(notification.group_jid.clone(), Arc::new(info)) | ||
| .await; | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When a participant removal succeeds while the group cache is warm, this new awaited persistence write runs before
rotate_sender_key_on_participant_remove; with SQLite or a custom backend this can block on disk/network while other outgoing sends are still allowed, so a concurrent send can reuse the old sender key after the server has accepted the removal. Move the rotation ahead of this best-effort metadata persistence (the same ordering exists in the group-notification remove path) so removed members cannot retain decryptable sender-key material during a slow metadata write.Useful? React with 👍 / 👎.