[BUG] Brazilian 9th digit lost in LID/PN mapping - messages remain PENDING

[giovanealvesdemedeiros-cloud]

📋 Bug Description

[BUG] Brazilian number loses 9th digit in LID/PN mapping and outbound messages stay PENDING

Environment

• Evolution API: v2.3.7
• Docker image: evoapicloud/evolution-api:latest
• Provider: Baileys
• Deployment: Docker / Ubuntu VPS
• Integration: n8n webhook
• PostgreSQL enabled
• Redis container present

Problem

Incoming WhatsApp messages are received, but Evolution/Baileys is mapping a Brazilian mobile number to an incorrect PN/JID.

Real phone number:

+55 47 98921-1984

Expected PN/JID:

5547989211984@s.whatsapp.net

Evolution resolves it as:

554789211984@s.whatsapp.net

The ninth digit 9 after Brazilian area code 47 is lost.

Evidence

Evolution log:

[OnWhatsappCache] [saveOnWhatsappCache] Register exists for [5547989211984@s.whatsapp.net,554789211984@s.whatsapp.net]? => 554789211984@s.whatsapp.net

Incoming events also showed LID addressing and remoteJidAlt.

A local session/volume inspection found this mapping:

185031603552434@lid -> 554789211984

The expected mapping would correspond to:

5547989211984@s.whatsapp.net

Direct outbound test

We bypassed n8n completely and sent directly through Evolution to:

185031603552434@lid

Result:

• HTTP: 201
• Message ID: 3EB0D17079F19FC30DC37A
• Final status: PENDING
• SERVER_ACK: not received
• DELIVERY_ACK: not received
• Message received by destination phone: NO

Therefore HTTP 201 only queued/accepted the message; it was never delivered.

Important observations

n8n is not the origin of the incorrect phone mapping.

The incorrect PN already exists in the Evolution/Baileys LID/PN mapping.

Updating/restarting Evolution did not correct the existing mapping.

Redis DBSIZE returned 0.

The WhatsApp connection itself remains active and incoming messages are received.

Expected behavior

For the Brazilian mobile number:

+55 47 98921-1984

Evolution/Baileys should resolve the phone JID as:

5547989211984@s.whatsapp.net

When an inbound event uses LID addressing, Evolution should maintain a correct and stable relationship between the LID and this PN.

A reply to the inbound contact must be delivered to the same WhatsApp user.

Actual behavior

Evolution/Baileys associates the contact with:

554789211984@s.whatsapp.net

instead of:

5547989211984@s.whatsapp.net

and direct outbound messages remain PENDING without SERVER_ACK or DELIVERY_ACK.

Request for maintainers

Could you please confirm:

1. Is this a known Brazilian 9th-digit issue in the current LID/PN mapping?
2. How can the incorrect cached/session mapping be safely rebuilt without deleting the entire WhatsApp instance?
3. Is there an upstream patch/commit that fixes this behavior on v2.3.7?
4. Is the recent LID → phone JID work intended to fix this case?
5. Is there a supported way to force Baileys/Evolution to refresh the LID ↔ PN association from WhatsApp?
6. Why does direct sendText return HTTP 201 but remain PENDING with no SERVER_ACK?

We can provide sanitized logs and additional diagnostic output if needed.

Please note that this is affecting a production customer-service automation because incoming messages are received but replies cannot reliably return to the sender.

🔄 Steps to Reproduce

1. Connect a Brazilian WhatsApp number to Evolution API v2.3.7 using Baileys.
2. From +55 47 98921-1984, send a WhatsApp message to the connected Evolution instance.
3. Evolution receives the incoming message using LID addressing.
4. Inspect the LID/PN mapping and remoteJid/remoteJidAlt.
5. Evolution maps the real number 5547989211984 to 554789211984, incorrectly removing the Brazilian ninth digit.
6. Reply directly through Evolution API to the received contact/LID.
7. The API returns HTTP 201, but the message remains PENDING with no SERVER_ACK or DELIVERY_ACK and is not delivered to the phone.

✅ Expected Behavior

For Brazilian WhatsApp numbers, Evolution API must preserve the correct phone number associated with the LID.

For this case, the real sender is:
+55 47 98921-1984

Expected PN/JID:
5547989211984@s.whatsapp.net

The LID must be mapped to 5547989211984, not to 554789211984.

When replying to the received message, Evolution API should route the response to the same real sender and obtain SERVER_ACK / DELIVERY_ACK instead of remaining PENDING.

❌ Actual Behavior

Evolution API receives the incoming WhatsApp message, but the LID is being associated with the wrong Brazilian phone number.

Real sender:
+55 47 98921-1984

Correct JID:
5547989211984@s.whatsapp.net

Incorrect mapping currently stored:
185031603552434@lid -> 554789211984

When Evolution replies using this mapping, sendText returns HTTP 201, but the message remains PENDING. No SERVER_ACK or DELIVERY_ACK is received and the message does not reach the real sender.

The incorrect PN mapping persists even after updating Evolution API v2.3.7 and restarting the instance.

🌍 Environment

• OS: [e.g. Ubuntu 20.04, Windows 10, macOS 12.0]
• Node.js version: [e.g. 18.17.0]
• Evolution API version: [e.g. 2.3.7]
• Database: [e.g. PostgreSQL 14, MySQL 8.0]
• Connection type: [e.g. Baileys, WhatsApp Business API]

📋 Logs

Evolution API: v2.3.7
Image: evoapicloud/evolution-api:latest

Real WhatsApp sender:
+55 47 98921-1984

Expected JID:
5547989211984@s.whatsapp.net

LID:
185031603552434@lid

Incorrect mapping found locally:
185031603552434@lid -> 554789211984

Direct send test:
HTTP: 201
Final status: PENDING
SERVER_ACK: not received
DELIVERY_ACK: not received
Message delivered to phone: NO

📝 Additional Context

This issue is affecting a production customer-service automation.

Incoming WhatsApp messages reach Evolution API and n8n correctly, but replies fail because the LID is mapped to an incorrect Brazilian PN.

We have already updated/restarted Evolution API and verified the mapping directly. We do not want to manually add/remove/reorder digits as a workaround.

Please identify the correct way to rebuild or refresh the LID -> PN mapping and confirm whether this is a known issue in v2.3.7 / Baileys.

If a fix, commit, newer image, cache reset procedure, or database repair exists, please provide the exact procedure.