client: auto re-invite idle-kicked GC members on return#776
Open
karamble wants to merge 2 commits into
Open
Conversation
handleGCInvite rejected any RMGroupInvite for a GC that already exists locally, storing nothing and firing no notification, so a stale local GC copy (e.g. after restoring an old backup) could never be recovered: the admin re-adds the user by re-inviting, but the invite was always dropped. Store the invite and notify even when the GC exists. The stale roster is refreshed by the normal RMGroupList update (maybeUpdateGC) once the invite is accepted, which already verifies the sender's admin permission and rejects generation backtracks.
When auto-remove-idle is enabled, a GC admin now tracks members it kicked for being idle. If such a member (who, being offline, never saw the kick and still believes they are a member) later sends a GC message, the admin re-adds them and broadcasts the updated member list instead of dropping the message; the returning member's roster refreshes via the normal RMGroupList update. Manual (non-idle) kicks and blocked users are never auto-re-added, and concurrent re-adds by multiple admins resolve via the existing generation guard. Adds a regression test.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Depends on #771 (this branch is stacked on
fix-gc-dropped-reinvite). Thefirst commit shown here belongs to #771 and the diff reduces to a single
commit once #771 merges, so this should be merged after it.
What
When auto-remove-idle is enabled (
AutoRemoveIdleUsersInterval > 0), a GCadmin now tracks the members it kicks for being idle. If such a member, who
was offline when kicked and so never saw the kick and still believes it is a
member, later sends a GC message, the admin re-adds it and broadcasts the
updated member list instead of silently dropping the message. The returning
member absorbs the new roster through the normal
RMGroupListupdate path; noinvite/accept round trip is needed because the KX survives the kick.
Details
{GCID}.kickedmembersstore, modeled on the existing.blocklist, and cleaned up inDeleteGC.GCKick) andwhen another admin's idle-kick is observed (
handleGCKick), so anyparticipating admin can later re-add the member.
handleGCMessagere-adds the member whenit was idle-kicked, the local client is an admin, and the member is not
blocked.
AutoRemoveIdleUsersInterval > 0, so it isinert for deployments that do not auto-remove idle users.
Edge cases
generation-backtrack guard.
Testing
Adds
TestGCAutoReinviteIdleKickedMember, which idle-kicks an offline-modeledmember and asserts the admin re-adds and re-broadcasts on the member's next
message; verified it fails without the change. The client package and GC e2e
suite pass.
Closes #726.