fix: use WWebJS.getChat for inviteV4 fallback in addParticipants

[ashmitmittal]

Description

GroupChat.addParticipants crashes with TypeError: this.findImpl is not a function when a participant can't be added directly and the inviteV4 fallback kicks in (RPC code 403, ParticipantRequestCodeCanBeSent).

The fallback looked up the participant's 1:1 chat via the legacy collection API:

window.require('WAWebCollections').Chat.get(pWid) ||
    (await window.require('WAWebCollections').Chat.find(pWid));

Current WhatsApp Web builds no longer implement findImpl on the Chat collection, so whenever the participant has no existing private chat — which is precisely the scenario where the invite fallback is needed — Chat.get misses and Chat.find throws.

This PR replaces that lookup with the library's own window.WWebJS.getChat() helper, which was already migrated to WhatsApp's supported WAWebFindChatAction.findOrCreateLatestChat API (#3703) and also creates the chat when it doesn't exist, handling LID/PN resolution. This mirrors how removeParticipants in the same file already resolves chats.

Note: this call site is the only remaining legacy Chat.find usage that structurally targets a user with no loaded chat, which is why it's the one crashing in the wild. Migrating the other (practically unreachable) legacy call sites could be a follow-up.

Related Issue(s)

fixes #201789

Testing Summary

Test Details

Fix is based on analysis of the stack trace in #201789: the crash originates at the legacy Chat.find call, and the replacement (window.WWebJS.getChat) is the same code path already exercised on current WhatsApp Web by getChatById and removeParticipants.

I could not yet reproduce the full scenario end-to-end (it requires a second account with group-add privacy set to "My contacts" and no prior chat with the account). Verification from the issue reporter, who has a reliable repro, would be appreciated.

eslint and prettier --check pass on the changed file.

Unrelated note: .husky/commit-msg uses the GNU-sed-only \L extension, which on macOS (BSD sed) prepends a literal L to the commit type, making every commit fail commitlint. Can open a separate PR for that.

Environment

• Machine OS: macOS 15
• Phone OS: Android
• Library Version: main (1.34.7)
• WhatsApp Web Version: 2.3000.x (current)
• Browser Type and Version: Chromium (Puppeteer 24.38.0 bundled)
• Node Version: 18+

Type of Change

• Dependency change (package changes such as removals, upgrades, or additions)
• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-code change (documentation, README, etc.)

Checklist

• My code follows the style guidelines of this project.
• All new and existing tests pass (npm test).
• Typings (e.g. index.d.ts) have been updated if necessary. (no signature change, not needed)
• Usage examples (e.g. example.js) / documentation have been updated if applicable. (not applicable)

[nirizr]

Sweet, this does look like a good fix for the issue I'm having! Thanks!

Unfortunately it isn't easy for me to reproduce at-will. This is a flow encountered in a production system with user accounts not under my control. I will report back as soon as I can but I'm looking forward to seeing this merged!

[nirizr]

Hey, I wanted to update that this fix works for me. Looking forward to seeing it in main!

[ashmitmittal]

Hey, I wanted to update that this fix works for me. Looking forward to seeing it in main!

great

[nirizr]

@BenyFilho Apologies for the mention, but how can I help in getting this merged in?

I'm asking because I think I identified another bug I'd like to report