Outgoing messages fail with MessageUpdate=ERROR for one Baileys session while another session on the same server succeeds

[correoiajjd-wq]

Welcome!

• Yes, I have searched for similar issues on GitHub and found none.

What did you do?

Environment

• Evolution API: 2.3.7
• Integration: WHATSAPP-BAILEYS
• Docker
• PostgreSQL 17
• Redis 7
• Android 12
• WhatsApp Messenger (Google Play)

Context

I connected two different WhatsApp accounts to the same Evolution API installation.

• Sender A
• Sender B

Both instances:

• were created the same way
• use the same Evolution API server
• use the same PostgreSQL database
• use the same Redis instance
• use the same Docker environment
• reached connectionStatus = open
• receive incoming events correctly

I then tested outgoing messages using the same endpoint:

POST /message/sendText/{instance}

using the same API key and sending messages to the same recipients.

Result

Sender B successfully delivers every tested message.

Sender A never delivers outgoing messages.

The API always returns:

{
  "status": "PENDING"
}

However, the final database status is different:

• Sender B → SERVER_ACK → DELIVERY_ACK
• Sender A → ERROR

The problem is reproducible with multiple destination phone numbers.

To rule out account corruption, I also:

• deleted the WhatsApp account
• uninstalled WhatsApp
• rebooted the phone
• installed WhatsApp again
• registered the number again
• created a brand new Evolution instance

The behavior remains exactly the same.

Additionally, the same problematic WhatsApp account works correctly with the official WhatsApp Web.

What did you expect?

Both WhatsApp accounts should behave identically.

After calling:

POST /message/sendText/{instance}

I expected both instances to:

1. accept the message,
2. send it successfully,
3. update the message status to:

SERVER_ACK
DELIVERY_ACK

The message should appear on the sender's phone and be delivered to the recipient, regardless of which WhatsApp account is connected, since both instances run on the same Evolution API installation and use the same configuration.

What did you observe instead of what you expected?

The behavior differs depending on which WhatsApp account is connected.

Sender A (problematic)

• The instance connects successfully (connectionStatus = open).
• Incoming messages and events are received correctly.
• POST /message/sendText returns PENDING.
• The message never appears on the sender's phone.
• The recipient never receives the message.
• The final status stored in MessageUpdate is ERROR.

Sender B (same server)

Using exactly the same infrastructure and configuration:

• The instance connects successfully.
• POST /message/sendText also returns PENDING.
• The message is delivered successfully.
• The final statuses are:
  • SERVER_ACK
  • DELIVERY_ACK

Additional observations

• Both instances use WHATSAPP-BAILEYS.
• Both instances are open.
• The issue occurs with multiple destination phone numbers.
• The problem persists after deleting the WhatsApp account, reinstalling the application, registering the account again, and creating a brand new Evolution instance.
• The problematic account works correctly with the official WhatsApp Web.

Screenshots/Videos

No response

Which version of the API are you using?

2.3.7

What is your environment?

Mac

Other environment specifications

• OS: macOS Sequoia 15.x (Apple Silicon)
• Deployment: Docker Compose
• Evolution API: 2.3.7
• Integration: WHATSAPP-BAILEYS
• Database: PostgreSQL 17
• Cache: Redis 7
• Phone: Android 12
• WhatsApp: WhatsApp Messenger (Google Play)

If applicable, paste the log output

The API accepts the request and returns:

{
"key": {
"remoteJid": "@s.whatsapp.net",
"fromMe": true,
"id": "<message_id>"
},
"status": "PENDING",
"messageType": "conversation"
}

However, the message is never delivered.

The corresponding MessageUpdate entries become:

Sender_A
ERROR

Sender_B
SERVER_ACK
DELIVERY_ACK

No useful errors are emitted in the Evolution logs, even with LOG_LEVEL=ERROR. The only recurring output consists of Baileys "Closing session" messages and cache updates, with no explicit relayMessage or send failure details.

Additional Notes

Additional technical observations

While investigating the issue, I compared the database records of both instances.

Both instances:

• are connectionStatus = open
• have number populated
• have ownerJid populated
• use WHATSAPP-BAILEYS
• are stored correctly in the Instance table

The only relevant difference I found is that one incoming message for the problematic account contains:

{
  "remoteJid": "<lid>@lid",
  "remoteJidAlt": "<phone>@s.whatsapp.net",
  "addressingMode": "lid"
}

I noticed that recent Evolution releases include several fixes related to LID (remoteJidAlt, addressingMode, etc.), so this information may be relevant.

I also verified that:

• the issue is not destination-specific (tested with multiple recipients)
• the issue is not instance-specific (multiple fresh instances were created)
• the issue is not account-state-specific (the WhatsApp account was deleted and recreated from scratch)
• the same WhatsApp account works correctly with the official WhatsApp Web

If needed, I can also provide:

• SQL queries used during the investigation
• database evidence (MessageUpdate)
• Docker compose files
• environment configuration
• additional tests or debug logs

I would be happy to run additional tests or build a custom branch if you need more information to reproduce or diagnose the issue.

[JhonnMeira]

Mesma coisa aqui, aparentemente é algum bloqueio no próprio WhatsApp; após um tempo, começa a entregar normalmente.