fix: store group notifications LID mappings

[gusquadri]

---

Summary by cubic

Persist LID↔PN mappings from group notifications to fix missing ID resolution in group events. Group w:gp2 notifications now extract and save mappings for all relevant participants, and continue processing even if mapping storage fails.

• Bug Fixes
  • Made handleGroupNotification async and awaited in the w:gp2 path.
  • Extract mappings from acting participant, group owner on create, participant entries, and membership request create/revoke events.
  • Store collected mappings via signalRepository.lidMapping.storeLIDPNMappings; on failure, log and proceed without dropping the notification.
  • Added LIDMapping type and applied isLidUser/isPnUser guards to avoid invalid entries.

^{Written for commit 722af7f. Summary will update on new commits.}

Summary by CodeRabbit

• Bug Fixes
  • Improved reliability of group notifications and member identification tracking.
  • More accurate handling of membership changes (create, add, remove, promote, demote, leave).
  • Corrected processing of membership approval and revocation notices to reflect proper status.
  • Ensured persistent storage of member mappings to keep group state consistent across devices.

[whiskeysockets-bot]

Thanks for opening this pull request and contributing to the project!

The next step is for the maintainers to review your changes. If everything looks good, it will be approved and merged into the main branch.

In the meantime, anyone in the community is encouraged to test this pull request and provide feedback.

✅ How to confirm it works

If you’ve tested this PR, please comment below with:

Tested and working ✅

This helps us speed up the review and merge process.

📦 To test this PR locally:

# NPM
npm install @whiskeysockets/baileys@gusquadri/Baileys#fix/group-notification-lid-mappings

# Yarn (v2+)
yarn add @whiskeysockets/baileys@gusquadri/Baileys#fix/group-notification-lid-mappings

# PNPM
pnpm add @whiskeysockets/baileys@gusquadri/Baileys#fix/group-notification-lid-mappings

If you encounter any issues or have feedback, feel free to comment as well.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: cf06784b-4260-438e-a284-172920317ee0

📥 Commits

Reviewing files that changed from the base of the PR and between 81f13b1 and 722af7f.

📒 Files selected for processing (1)

• src/Socket/messages-recv.ts

---

📝 Walkthrough

Walkthrough

Group notification handling now collects LID↔PN mappings from acting participants, group owners, participant list changes, and membership requests; the handler is async and persists collected mappings via signalRepository.lidMapping.storeLIDPNMappings after processing.

Changes

Group Notification LID/PN Mapping Collection

Layer / File(s)	Summary
Import and async conversion src/Socket/messages-recv.ts	LIDMapping type imported; handleGroupNotification converted to async with initialization of lidPnMappings and extraction of acting participant LID/PN.
Group owner mapping on creation src/Socket/messages-recv.ts	Group owner's LID↔PN mapping captured when both identifiers validate during group creation.
Participant state change mappings src/Socket/messages-recv.ts	Participant node attributes (phoneNumber, lid) derived for promote/demote/remove/add/leave and created_membership_requests; corresponding LID↔PN mappings accumulated.
Revoked requests and persist src/Socket/messages-recv.ts	revoked_membership_requests stub changed to include only revoked/rejected; affected participant mapping recorded and any collected mappings persisted via signalRepository.lidMapping.storeLIDPNMappings(...) with warning-on-failure.
Dispatcher call update src/Socket/messages-recv.ts	w:gp2 notification case updated to call handleGroupNotification(node, child!, result) with the async signature.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 I hopped through group-notifs, keen and spry,
LIDs and PNs I gently tie,
From owners, actors, members too,
I gather pairs and store them true,
A little async hop — mappings safe and dry.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fix: store group notifications LID mappings' accurately and concisely summarizes the main change: persisting LID↔PN mappings from group notifications.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cubic-dev-ai]

Review completed

_{Re-trigger cubic}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/Socket/messages-recv.ts`:
- Around line 966-968: handleGroupNotification currently awaits the ancillary
call signalRepository.lidMapping.storeLIDPNMappings(lidPnMappings) which can
throw and abort the main notification flow; change this so mapping persistence
is isolated: wrap the call to
signalRepository.lidMapping.storeLIDPNMappings(...) (and the lidPnMappings
check) in a try/catch inside handleGroupNotification (or immediately around the
existing await), log any error but do not rethrow, or run the store call
asynchronously without awaiting it so transient failures don’t cause
handleGroupNotification/handleNotification to reject and prevent the synthetic
group event upsert from occurring.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 5cdb7b3a-fe88-4e40-966c-aeb0c318988d

📥 Commits

Reviewing files that changed from the base of the PR and between 78e7e4e and 81f13b1.

📒 Files selected for processing (1)

• src/Socket/messages-recv.ts

[jlucaso1]

The changes seem good to me. Could you add some tests to ensure I don't regret it later? I'm thinking of refactoring all of these lid-pn learning paths later, as we're unnecessarily duplicating a lot of logic