Follow-up from PR #167 review (GroupV2Convo::add_member, core/conversations/src/conversation/group_v2.rs).
pending_invites records who we invited so after_op can route each joiner's welcome on the matching WelcomeReady. Entries are removed only on a WelcomeReady match or an immediate add_member failure. There is no eviction for a proposal that opens but never yields a WelcomeReady (e.g. a commit that never reaches consensus): the entry leaks and can later match a re-join, firing a spurious duplicate welcome.
The recording-time guard added in #167 closes the self / already-member cases and within-batch duplicates, so this is the remaining gap.
What's needed
- Evict or reconcile
pending_invites when an add does not commit: a TTL, or a reconcile against the committed roster on wakeup.
Raised by @jazzz (review: "should this check occur when pending_invites is processed in after_op").
Follow-up from PR #167 review (
GroupV2Convo::add_member,core/conversations/src/conversation/group_v2.rs).pending_invitesrecords who we invited soafter_opcan route each joiner's welcome on the matchingWelcomeReady. Entries are removed only on aWelcomeReadymatch or an immediateadd_memberfailure. There is no eviction for a proposal that opens but never yields aWelcomeReady(e.g. a commit that never reaches consensus): the entry leaks and can later match a re-join, firing a spurious duplicate welcome.The recording-time guard added in #167 closes the self / already-member cases and within-batch duplicates, so this is the remaining gap.
What's needed
pending_inviteswhen an add does not commit: a TTL, or a reconcile against the committed roster on wakeup.Raised by @jazzz (review: "should this check occur when pending_invites is processed in after_op").