[BUG] Inbound messages received by Baileys are not emitted as MESSAGES_UPSERT webhooks; instance gets stuck and cannot be deleted until restart

Trace the Baileys inbound message path from receipt through MESSAGES_UPSERT and webhook dispatch, then compare it with the instance delete/logout path. Start with the TRACE and Baileys logs, including the LID/PN, session, and decryption errors. Done means affected inbound messages produce webhooks and the connected instance remains manageable without a restart.

Welcome!

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

What did you do?

We are running Evolution API in production using a Baileys WhatsApp instance with webhook integration to n8n.

The system works normally for most messages. However, after the instance runs for some time, some inbound customer messages become visible in the WhatsApp mobile app but do not trigger a MESSAGES_UPSERT webhook.

To debug this, we enabled trace logging:

LOG_LEVEL=TRACE
LOG_BAILEYS=trace
LOG_COLOR=false

Then we compared the same affected message time windows across:

• WhatsApp mobile app message timestamps
• Evolution/Baileys container logs
• Reverse proxy logs
• n8n execution logs

We found multiple cases where the inbound message reached the Evolution/Baileys layer, but no webhook POST was sent to n8n.

We also noticed that around the same time this starts happening, Evolution Manager sometimes fails to delete the affected instance and shows:

Error: [object Object]

After restarting only the evolution-api container, the delete action works again.

If we delete and reconnect a fresh instance, webhook delivery becomes stable again for a few days, then the issue returns.

What did you expect?

Every inbound WhatsApp text message received by the Baileys socket should emit a normal MESSAGES_UPSERT webhook to the configured webhook URL.

If Evolution cannot process or emit the message, it should log a clear error explaining why the webhook was not emitted.

The instance should also remain manageable from Evolution Manager. Actions like delete/logout should not fail while the instance is shown as connected.

What did you observe instead of what you expected?

Some inbound WhatsApp messages are visible in the WhatsApp mobile app, but Evolution does not emit a MESSAGES_UPSERT webhook for those messages.

For affected messages:

• No HTTP POST reaches the reverse proxy
• No n8n execution is created
• No downstream chat history row is created
• Sometimes the message appears in Evolution/Baileys logs as a raw packet
• Sometimes the message is even parsed/readable in Evolution logs, but still no webhook is dispatched
• Sometimes the message appears later through a delayed/raw/sync-like path, but still no webhook is emitted

We observed these patterns:

Pattern 1: Message readable in Evolution logs, but no webhook

A customer sent:

Please place the order

Evolution/Baileys logs showed a readable message object:

remoteJid: 94XXXXXXXXX@s.whatsapp.net
remoteJidAlt: 94XXXXXXXXX@s.whatsapp.net
conversation: "Please place the order"

But during the same time window:

No messages.upsert event
No webhook dispatch log
No HTTP POST in reverse proxy logs
No n8n execution

Pattern 2: Raw encrypted packet received, but no readable conversation and no webhook

Another affected message appeared as:

<message from="REDACTED_LID@lid" type="text" id="REDACTED_MESSAGE_ID" notify="REDACTED_NAME" sender_pn="94XXXXXXXXX@s.whatsapp.net">
  <enc v="2" type="pkmsg">REDACTED_ENCRYPTED_PAYLOAD</enc>
</message>

Then Evolution logged PN/LID mapping and device/session activity, but no readable conversation: object and no webhook.

Pattern 3: Message appears later in logs but never emits webhook

One customer message was visible in WhatsApp at the original send time. Evolution did not emit a webhook at that time.

Around one hour later, Evolution logs showed the same message ID and sender number in a raw/sync-like path:

<message from="REDACTED_LID@lid"
         type="text"
         id="REDACTED_MESSAGE_ID"
         offline="0"
         notify="REDACTED_NAME"
         sender_pn="94XXXXXXXXX@s.whatsapp.net"
         t="REDACTED_TIMESTAMP">
  <url_number />
  <unavailable />
</message>

The same message ID later appeared again with encrypted content:

<message from="REDACTED_LID@lid"
         type="text"
         id="REDACTED_MESSAGE_ID"
         sender_pn="94XXXXXXXXX@s.whatsapp.net">
  <enc v="2" type="pkmsg">REDACTED_ENCRYPTED_PAYLOAD</enc>
</message>

But again there was:

No readable conversation
No messages.upsert webhook
No HTTP POST to n8n

Around the same period, Evolution Manager sometimes cannot delete the instance and shows:

Error: [object Object]

After restarting the evolution-api container, the delete action works again.

Screenshots/Videos

I can provide screenshots and additional logs if needed.

For privacy/security reasons, I am not attaching production screenshots in the initial report because they contain customer phone numbers, profile names, instance names, webhook URLs, and internal workflow details.

Available evidence if maintainers need it:

• Evolution Manager delete error screenshot (Error: [object Object])
• WhatsApp screenshot showing the inbound message visible in the app
• n8n execution window showing no execution for the affected timestamp
• Sanitized Evolution/Baileys logs
• Sanitized reverse proxy logs showing no HTTP POST for the affected message window

Which version of the API are you using?

2.3.7

What is your environment?

Linux

Other environment specifications

Deployment:

• Ubuntu Linux server
• Docker Compose
• Evolution API container
• PostgreSQL enabled
• Redis enabled
• Reverse proxy in front of n8n
• n8n webhook receiver
• WhatsApp instance type: Baileys / WhatsApp Web

Relevant Evolution environment settings:

LOG_LEVEL=TRACE
LOG_BAILEYS=trace
LOG_COLOR=false

REDIS_ENABLED=true
REDIS_URI=redis://redis:6379/1
REDIS_PREFIX_KEY=evocore

CACHE_REDIS_ENABLED=true
CACHE_REDIS_URI=redis://redis:6379/2
CACHE_REDIS_PREFIX_KEY=evocache
CACHE_LOCAL_ENABLED=false

DATABASE_ENABLED=true
DATABASE_PROVIDER=postgresql

STORE_MESSAGES=false
STORE_MESSAGE_UP=false
STORE_CONTACTS=false
STORE_CHATS=false

NODE_OPTIONS=--max-old-space-size=1024

Main enabled event:

MESSAGES_UPSERT

Traffic source:

• Normal WhatsApp customer messages
• Click-to-WhatsApp ads from Facebook/Instagram

If applicable, paste the log output

Sanitized log samples:

Raw message packet received

<message from="REDACTED_LID@lid"
         type="text"
         id="REDACTED_MESSAGE_ID"
         offline="0"
         notify="REDACTED_NAME"
         sender_pn="94XXXXXXXXX@s.whatsapp.net"
         t="REDACTED_TIMESTAMP">
  <url_number />
  <unavailable />
</message>

Same message ID later appears with encrypted content

<message from="REDACTED_LID@lid"
         type="text"
         id="REDACTED_MESSAGE_ID"
         sender_pn="94XXXXXXXXX@s.whatsapp.net">
  <enc v="2" type="pkmsg">REDACTED_ENCRYPTED_PAYLOAD</enc>
</message>

PN/LID mapping and device migration logs

Cache miss for PN user 94XXXXXXXXX; checking database
Storing 1 pn mappings
bulk device migration - loading all user devices
sent ack
LID mapping already exists, skipping

Example of readable message with no webhook

remoteJid: 94XXXXXXXXX@s.whatsapp.net
remoteJidAlt: 94XXXXXXXXX@s.whatsapp.net
conversation: "Please place the order"

But for the same message window:

No messages.upsert event
No webhook dispatch log
No HTTP POST in reverse proxy logs
No n8n execution

Other related errors seen during affected periods

Failed to decrypt message with any known session
Session error: Error: Bad MAC
Decrypted message with closed session
Invalid patch mac
failed to sync state from version, removing and trying from scratch

Downstream verification

For the affected message windows:

No webhook POST in reverse proxy logs
No n8n execution
No downstream chat_history row

Additional Notes

This is production-impacting because customer messages are silently missed.

Important observations:

1. Restarting the evolution-api container temporarily restores Manager actions such as delete.
2. Deleting the old instance and creating/reconnecting a fresh instance temporarily fixes message delivery for a few days.
3. After several days of production usage, the issue returns.
4. This suggests the Baileys/Evolution instance state may degrade or become desynced over time.
5. The issue seems related to LID/PN mapping, session/pre-key state, app-state sync, event buffering, or webhook emission.

Questions:

1. Is this a known issue in v2.3.7?
2. Could this be related to LID/PN mapping, app-state sync, pre-key/session state, or event buffer flushing?
3. Is there a safe way to repair/reset an instance state without deleting and reconnecting it?
4. Should we enable STORE_MESSAGES, STORE_MESSAGE_UP, STORE_CHATS, or other storage options to improve recovery?
5. Is it recommended to enable additional events such as MESSAGES_SET, MESSAGES_UPDATE, or CHATS_UPDATE to recover messages that do not emit as MESSAGES_UPSERT?
6. Should we avoid using latest and pin a specific stable version?
7. Is there a recommended stable version for production use with Redis + PostgreSQL + Baileys?