Webhook not firing (MESSAGES_UPSERT) and outbound messages "succeed" without delivery — instance connected, both directions failing silently

[alcioneflorek-alt]

Welcome!

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

What did you do?

Environment

• Evolution API version: 2.3.7 (client self-identifies as this version in Integrations panel; attempted downgrade to 2.3.6 via Docker image tag did not take effect — image kept reporting 2.3.7)
• Deployment: Railway
• Baileys version: 2.3000.1045164762
• Instance name: afprospeccao2

Steps to reproduce (inbound)

1. Created a brand-new instance (afprospeccao2) from scratch after fully cleaning up old instance data (Redis keys, Postgres phantom instance records)
2. Connected the instance to WhatsApp — status shows "Connected"
3. Configured webhook via the UI: enabled, correct URL, event MESSAGES_UPSERT (confirmed in Settings → Behavior)
4. Sent a test message from another phone — message shows delivered/read (double blue check) on WhatsApp
5. No webhook call is received on the destination server (verified independently — manually POSTing a synthetic payload to the same endpoint works correctly)
6. Reconfigured the webhook via API directly (POST /webhook/set/{instance}) to rule out a UI persistence bug — API responded 201 with correct config
7. Sent another test message after reconfirming — still no webhook dispatch

Steps to reproduce (outbound)

1. n8n workflow calls /message/sendText/{instance} via HTTP Request node
2. The Evolution API call returns a success response — n8n marks the execution as "Succeeded"
3. No message is actually delivered to the WhatsApp recipient
4. This has been consistently observed across multiple executions (e.g. one batch of 5 messages, all returned success in the API/n8n but none were delivered)
5. messageStubParameters: ["463"] appeared consistently in these failed outbound deliveries in earlier debugging

What did you expect?

Inbound: the webhook should fire a MESSAGES_UPSERT event POST to the configured URL whenever a new message is received.

Outbound: a "success" response from /message/sendText should mean the message was actually delivered (or at minimum reflect real delivery status, not just that the API call was accepted).

What did you observe instead of what you expected?

Inbound: no webhook request is ever received on the destination server, despite the instance showing "Connected" and messages being confirmed delivered/read on WhatsApp. Confirmed the destination server itself works correctly by manually POSTing a synthetic payload to it (processed successfully). Also confirmed the webhook config is correctly persisted by re-setting it via direct API call, which returned 201 with the correct configuration — yet no dispatch occurs on real incoming messages.

Outbound: /message/sendText returns a success response and n8n marks the workflow execution as "Succeeded", but the message is never actually delivered to the recipient's WhatsApp. Observed across multiple executions, including one batch of 5 messages where all 5 "succeeded" at the API level but zero were delivered.

This suggests an issue in the underlying Baileys/WhatsApp event handling layer in this version — both inbound and outbound message flows silently fail after reporting success, with instance connection status appearing normal throughout.

Screenshots/Videos

No response

Which version of the API are you using?

2.3.7

What is your environment?

Windows

Other environment specifications

Deployment: Docker container on Railway. Instance name: afprospeccao2. Baileys version: 2.3000.1045164762.

If applicable, paste the log output

No raw application logs captured at time of reporting — all evidence gathered via API responses and n8n execution history, detailed in the reproduction steps above.

Additional Notes

This bug affects a production WhatsApp automation used for business messaging, causing both inbound customer messages and outbound automated messages to silently fail without any error indication in the API or n8n logs.

[alcioneflorek-alt]

Update: found a recurring database connectivity failure that likely explains this

Pulled the Railway deploy logs for the Evolution API service and found a PrismaClientKnownRequestError (code P1001, "Can't reach database server at postgres.railway.internal:5432") recurring consistently every ~10 minutes over an extended period (observed from 19:35 to 21:01 BRT on the same day), always during integrationSession.update() / io.findSettings() calls — i.e. right when the API tries to read or persist settings/session data, including webhook configuration.

Example log entry:

PrismaClientKnownRequestError:
Invalid a.integrationSession.update() invocation
Can't reach database server at postgres.railway.internal:5432
Please make sure your database server is running at postgres.railway.internal:5432.
code: 'P1001'
meta: { modelName: 'Setting', database_location: 'postgres.railway.internal:5432' }

A related P2024 ("Timed out fetching a new connection from the connection pool... Current connection pool timeout: 10, connection limit: 97") also appeared in the same window, suggesting the Postgres connection pool is being exhausted or the internal Railway network link to Postgres is intermittently dropping.

This would explain both symptoms reported above: if the API can't reliably read/write its own Settings/webhook config from the database, webhook dispatch and session-dependent behavior would silently fail even when the webhook appears correctly configured via the API/UI.