fix: reset user conversation seq when rejoining group to resolve message recall issue

[zhouribin]

📝 Description

This PR fixes a bug where members who quit and rejoin a group cannot recall their new messages or view new history correctly.

🐛 Issue

When a member quits a group, their userMaxSeq is capped at the current group maxSeq to restrict access to future messages. However, when the user rejoins, this userMaxSeq limit was not being cleared.

As a result, new messages (which have a higher seq) are filtered out by the visibility logic, causing "RecordNotFoundError" errors on the server side and preventing operations like message recall.

💡 Solution

I implemented a mechanism to reset the conversation visibility for a user immediately after they successfully rejoin a group.

Specific changes:

1. Introduced a helper function setMemberJoinSeq in internal/rpc/group/group.go.
2. This function performs the following:
   • Sets the user's minSeq to currentGroupMaxSeq + 1 (ensuring they don't see messages from before they rejoined).
   • Resets the user's userMaxSeq to 0 (removing the read limit so they can receive new messages).
3. Applied this reset logic to all group join paths:
   • Direct Join (JoinGroup)
   • Invitation (InviteUserToGroup)
   • Admin Approval (GroupApplicationResponse)

🔍 Verification

• Verified that rejoining members can now successfully pull new messages.
• Confirmed that message recall works as expected for messages sent after rejoining.
• Checked that userMinSeq is correctly updated and userMaxSeq is reset to 0 in the conversation settings.

[github-actions]

🤖 All Contributors have signed the CLA.
The signed information is recorded here
_{Posted by the CLA Assistant Lite bot.}

[zhouribin]

💕 Thank you for your contribution and please kindly read and sign our CLA. CLA Docs

I have read the CLA Document and I hereby sign the CLA

You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.

I have read the CLA Document and I hereby sign the CLA

[zhouribin]

I have read the CLA Document and I hereby sign the CLA

[zhouribin]

• Thanks for the follow-up review. Here is the updated clarification based on the latest change:

  • Change: In setMemberJoinSeq , replace 0 with math.MaxInt64 to set user MaxSeq to an “unlimited” value ( internal/rpc/group/group.go:972–975 ).
  • Why:
    • maxSeq=0 triggers Conversation service validation ( 1001 ArgsError ), which breaks invites.
    • Any small positive userMaxSeq shrinks the query upper bound below conversation maxSeq , which breaks revoke after join.
    • math.MaxInt64 preserves the “no upper limit” semantics and avoids both issues.
  • Safety:
    • History visibility remains controlled by the notification flow: when EnableHistoryForNewMembers=false , we set minSeq = maxSeq + 1 ( internal/rpc/group/notification.go:583–592 ).
    • Quit behavior is unchanged: user MaxSeq is solidified to the current conversation maxSeq ( internal/rpc/group/group.go:963–970 ).
  • Entry points: setMemberJoinSeq is invoked in all three paths for consistency:
    • GroupApplicationResponse ( internal/rpc/group/group.go:843–845 )
    • JoinGroup ( internal/rpc/group/group.go:908–910 )
    • InviteUserToGroup ( internal/rpc/group/group.go:459–461 )
  • Client consistency: using conversation.SetConversationMaxSeq ( pkg/rpcli/conversation.go:17–23 ) to keep conversation and seq_user in sync.
  • Commit: 36915fc on branch fix/group-member-rejoin-bug .

  @FGadvancer

[FGadvancer]

Thank you very much for submitting this PR.
Could you please also submit the same PR to the 3.8.3-patch branch?
This would allow us to release it to release as soon as possible.

[FGadvancer]

One more note regarding the condition maxSeq <= 0:
we may want to consider removing the = in the future and using a stricter comparison instead.
This would likely require a protocol-level change.

For now, keeping the value unified as 0 could help make the judgment logic more consistent across modules going forward.

[zhouribin]

Thank you very much for submitting this PR. Could you please also submit the same PR to the 3.8.3-patch branch? This would allow us to release it to release as soon as possible.

Hi @FGadvancer

• I’ve submitted the same fix to the 3.8.3-patch branch (branch fix/group-member-rejoin-bug-3.8.3 ; PR Fix/group member rejoin bug 3.8.3 #3646).