PRs 124-129 replaced TypeScript non-null assertions (!) with optional
chaining (?.) and empty string defaults (?? ''). While defensive
programming is usually good, in Signal protocol and WhatsApp binary
node handling code these changes caused:
- Malformed JIDs with empty user components (e.g. @s.whatsapp.net)
- Silent device enumeration failures (messages skip recipients)
- Wrong own-device detection (message routing errors)
- Broken prekey count handling (prekey uploads silently skipped)
- Wrong retry count tracking in Signal protocol
These empty-string defaults are dangerous because Signal session
lookups fail for malformed JIDs, causing "SessionError: No sessions".
Reverted to original Baileys pattern using non-null assertions (!)
which match the upstream reference (infinitezap/Teste_InfiniteAPI).
Files fixed: messages-send.ts, messages-recv.ts, socket.ts, chats.ts,
groups.ts, communities.ts, business.ts
https://claude.ai/code/session_01XaA7GwNaB6azTHFYQ8WEpB
Fixes:
- chats.ts: revert encodeResult/initial to ! (guaranteed by callback assignment)
- groups.ts: fix operator precedence with ?? (wrap +attrs in parens), fix groupId type
- messages-recv.ts: extract messageKey.id to local const with fallback
- socket.ts: revert onClose! (guaranteed by synchronous callback assignment)
- event-buffer.ts: add 'notify' fallback for MessageUpsertType
- messages.ts: add filePath const after null guard, fix contextInfo type assertion
- noise-handler.ts: restore array index ! (guaranteed by length check)
Build now compiles with zero new errors.
https://claude.ai/code/session_01E2cfX1N3sJgCJBTvzGazSG
* fix: fetchLatestWaWebVersion to curl
* fix: lint
* fix: fetchLatestWaWebVersion to bypass WhatsApp anti-bot detection with minimal headers
---------
Co-authored-by: João Lucas <jlucaso@hotmail.com>
* lid-mapping: get missing lid from usync
* lid-mapping, jid-utils: change to isPnUser and store multiple mappings
* process-message: parse protocolMsg mapping, and store from new msgs
* types: lid-mapping event, addressing enum, alt, contact, group types
* validate, decode: use lid for identity, better logic
* lid: final commit
* linting
* linting
* linting
* linting
* misc: fix testing and also remove version json
* lint: IDE fucking up lint
* lid-mapping: fix build error on NPM
* message-retry: fix proto import
* chore: remove comments and veirfy from generated proto files (improve size)
* refactor: replace fromObject with create for proto message instantiation and flag no beautiful
* chore: lint issues
* feat: implement basic newsletter functionality with socket integration and event handling
* feat: enhance media handling for newsletters with raw media upload support
* feat: working updatePicture, removePicure, adminCount, mute, Unmute
* fix: fetchMessages
* chore: cleanup
* fix: update newsletter metadata path and query ID for consistency. newsletterMetadata works now
* chore: enhance newsletter metadata parsing and error handling
* fix: correct DELETE QueryId value in Newsletter.ts
* chore: split mex stuffs to own file
* chore: remove as any
If the user does not allow to be added directly, it will be possible to get the invite code and create an invitation message for the user to join the group
The new proto extract has a bunch of breaking changes, so if you were using the raw proto in your code somewhere -- then you may have to update your code to make it work with the new proto
!BREAKING_CHANGE
!BREAKING_CHANGE
1. this allows all offline notifications to be combined into a batch -- to reduce the number of events being sent out
2. to enable the above, the "message.reaction" event has been made an array. Also removes the need for the "operation" field
3. have also now started processing all events under a single queue to prevent state sync problems
Claude