Patch/lid history and sync progress#2627
Open
vraj-sondagar-ridgelabs wants to merge 8 commits into
Open
Conversation
Two local patches on top of evolution-api v2.3.7: 1. @lid-history bridge (whatsapp.baileys.service.ts) The messages.upsert (live) path rewrites @lid -> real phone via remoteJidAlt, but messaging-history.set (bulk history) did not, so old @lid chats had no phone/name bridge. Preserve remoteJidAlt on history message keys (from itself or senderPn/participantAlt/ participantPn fallbacks) so a downstream resolver can map an old @lid chat to the saved contact name/number. 2. Real history-sync progress (whatsapp.baileys.service.ts + monitor.service.ts) Baileys emits a real 0-100 `progress` + `isLatest` on messaging-history.set, previously only wired to Chatwoot import. Record it on a public historySync field and surface it on the instanceInfo/fetchInstances response so clients can show a true progress bar instead of inferring from row counts. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
logoutInstance() called `await this.client.logout()` unguarded. When the WhatsApp socket is already down (user removed the device from their phone, or a dropped connection), client.logout() throws "Connection Closed", which aborted the function BEFORE the credential-purge block that deletes the Baileys auth (Session row). The creds survived, so recreating the same-named instance silently reconnected without a QR — "logout didn't work / still reconnects". Wrap client.logout() (and ws.close()) in try/catch so the credential purge ALWAYS runs. A failed WS logout on an already-closed socket is harmless. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add POST /chat/requestHistory/:instance { remoteJid, count? } which calls
Baileys' fetchMessageHistory(count, oldestKey, oldestTimestamp) anchored on
the oldest stored message of the chat. WhatsApp's initial multi-device sync
only delivers a bounded window per chat, so old messages of a specific chat
can be missing even when the DB holds years of other chats. Results arrive
async via the messaging-history.set ON_DEMAND path and get persisted.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add POST /chat/resolveLid/:instance { lids: string[] } -> { "<lid>": "<phone>|null" }.
Uses signalRepository.lidMapping.getPNForLID to recover the real phone for
@lid privacy/business chats that carry no remoteJidAlt in any stored message
(so the message-key and picture bridges can't resolve them). Last-resort
phone bridge for the "empty contact number" case.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Sorry @vraj-sondagar-ridgelabs, you have reached your weekly rate limit of 500000 diff characters.
Please try again later or upgrade to continue using Sourcery
Each synced Baileys Contact carries both its phone JID (contact.id = <phone>@s.whatsapp.net) and its @lid (contact.lid), but upstream discarded contact.lid — so an @lid chat could never be mapped back to the phone, and thus to the user's saved address-book name (chats showed the contact's own profile name like "." or an emoji instead of "Sahil Boulder"). Now on contacts.upsert we: 1. feed every (lid, pn) pair into Baileys' lidMapping store (signalRepository.lidMapping.storeLIDPNMappings) so getPNForLID() resolves them afterwards, and 2. persist an @lid Contact row mirroring the saved pushName, so the DB name-resolver bridges @lid -> saved name directly. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Evolution's publish_docker_image*.yml workflows try to build + push to Docker Hub on every push and fail (no DOCKERHUB secrets in this fork), spamming Actions failure emails. We build the image locally, so drop the CI entirely. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
getPNForLID returns the PN as '<phone>:0@s.whatsapp.net'. Stripping only '@...' left the ':0' whose colon got removed by replace(/\D/g), producing a spurious trailing '0' (919408740590 -> 9194087405900). Split on ':' too. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
When the live lidMapping has no PN for an @lid, fall back to ONE raw SQL over the chat's entire stored history, checking every field WhatsApp can leak the phone in: key.remoteJidAlt / senderPn / participantAlt / participantPn and contextInfo.participant. Also reject junk (<8 digit) results so a bare device index never renders as '+0'. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📋 Description
🔗 Related Issue
Closes #(issue_number)
🧪 Type of Change
🧪 Testing
📸 Screenshots (if applicable)
✅ Checklist
📝 Additional Notes