InfiniteAPI

You've already forked InfiniteAPI

Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Compare commits

merge into: ruicesar/InfiniteAPI:test/state-mar19-after-303-past

ruicesar/InfiniteAPI:archive/master-pre-restore-2026-05-01

pull from: ruicesar/InfiniteAPI:fix/past-participants-normalization

Branches Tags

ruicesar/InfiniteAPI:archive/master-pre-restore-2026-05-01

1 Commits

test/state-mar19-after-303-past .. fix/past-participants-normalization

Author	SHA1	Message	Date
Renato Alcara	64ec22d436	fix: add pastParticipants to HistorySync with LID normalization and deduplication Two bugs fixed compared to prior implementation: 1. history.ts — normalize userJid LID→PN pastParticipants[].userJid may arrive as a LID identifier (e.g. "46802258641027@lid"). The consumer expects a phone number. After building the lidPnMap from conversations and phoneNumberToLidMappings, each userJid is resolved to its PN equivalent. If the mapping is not available the original value is preserved (no data loss). 2. event-buffer.ts — deduplicate by groupJid + userJid across chunks Multiple HistorySync chunks can contain the same group. The previous approach concatenated blindly, producing duplicate entries. Now a keyed map { [groupJid]: IPastParticipant[] } is used so each group appears once and each participant within a group appears at most once. Types updated (Events.ts): - messaging-history.set event includes pastParticipants?: IPastParticipants[] - BufferedEventData.historySets.pastParticipants typed as keyed map Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-03-19 16:21:19 -03:00

Author

SHA1

Message

Date

Renato Alcara

64ec22d436

fix: add pastParticipants to HistorySync with LID normalization and deduplication

Two bugs fixed compared to prior implementation:

1. history.ts — normalize userJid LID→PN
   pastParticipants[].userJid may arrive as a LID identifier (e.g. "46802258641027@lid").
   The consumer expects a phone number. After building the lidPnMap from conversations
   and phoneNumberToLidMappings, each userJid is resolved to its PN equivalent.
   If the mapping is not available the original value is preserved (no data loss).

2. event-buffer.ts — deduplicate by groupJid + userJid across chunks
   Multiple HistorySync chunks can contain the same group. The previous approach
   concatenated blindly, producing duplicate entries. Now a keyed map
   { [groupJid]: IPastParticipant[] } is used so each group appears once and
   each participant within a group appears at most once.

Types updated (Events.ts):
   - messaging-history.set event includes pastParticipants?: IPastParticipants[]
   - BufferedEventData.historySets.pastParticipants typed as keyed map

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-03-19 16:21:19 -03:00

Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL

Expand all files Collapse all files

Compare commits

1 Commits test/state-mar19-after-303-past .. fix/past-participants-normalization

Diff Content Not Available

1 Commits

test/state-mar19-after-303-past .. fix/past-participants-normalization