InfiniteAPI

You've already forked InfiniteAPI

Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Compare commits

merge into: ruicesar/InfiniteAPI:fix/past-participants-normalization

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

pull from: ruicesar/InfiniteAPI:test/state-mar19-after-303-past

Branches Tags

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

1 Commits

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

Author	SHA1	Message	Date
Renato Alcara	6c52b01ea7	fix: add pastParticipants to HistorySync with LID normalization and deduplication (#303 ) 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	2026-03-19 16:44:14 -03:00

Author

SHA1

Message

Date

Renato Alcara

6c52b01ea7

fix: add pastParticipants to HistorySync with LID normalization and deduplication (#303 )

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

2026-03-19 16:44:14 -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 fix/past-participants-normalization .. test/state-mar19-after-303-past

Diff Content Not Available

1 Commits

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