[Bug]: The messages are not displayed.

[leonardoagudelo]

Pre-flight

• I searched existing issues and this isn't a duplicate
• I'm on the latest released version (or noted my version below)

OpenWA version

v0.8.17

Deployment

Docker Compose

Database

SQLite (default)

WhatsApp engine

whatsapp-web.js

What happened?

I developed a local app that consumes the OpenAI API. As of today, it isn't loading the messages. When I access the OpenWA web environment, I see what is shown in the attached image.

I restarted the session, deleted it, and created another one, but it's still working the same way.

Steps to reproduce

1. Simply go to Chats on the web configuration platform.

Expected behavior

No response

Relevant logs

Environment / additional context

No response

[cuonghuunguyen]

Baileys got the bug also

[darkman88]

Same problem here, but I noticed that chats get downloaded because on the dashboard the chart shows the number of messages received and the contact names.

[rmyndharis]

Thanks for the report — this is the same root cause as #757, and it's already fixed in v0.8.18.

What's happening

The screenshot is the key detail: this isn't an empty chat list, it's GET /api/sessions/:id/chats returning a 500. "Sin chats" is just the empty state left behind after the request throws.

WhatsApp Web build 2.3000.x (rolled out around 2026-07-14) renamed the internal serialized-id property on message keys from _serialized to $1. whatsapp-web.js 1.34.7's injected getChatModel reads chat.lastReceivedKey._serialized to resolve each chat's last message. That property is now undefined, and the follow-up lookup throws inside the page. Because getChats() resolves every chat through a single Promise.all, one chat is enough to reject the whole call — so the entire Chats page 500s.

This is why the rest of the dashboard still looked healthy (@darkman88 — your observation matches exactly): the message counts and contact names are read from the database, which inbound events kept populating. Only the live engine read crashed.

Fix

v0.8.18 backports the upstream whatsapp-web.js fix into the installed dependency at build time, which restores the id reads this path depends on. v0.8.17 predates it.

docker compose pull && docker compose up -d

One note on the release notes: the v0.8.18 entry describes this fix in terms of media downloads, message ids, acks, and reply quoting, and doesn't call out the Chats page explicitly — but the same patch covers it. That omission is on me; I'll get the changelog amended so it's findable.

Please reopen if you still see the 500 after upgrading, with docker compose logs from a fresh request.

@cuonghuunguyen — re: "Baileys got the bug also"

Baileys doesn't share this code path. Its getChats() reads from an in-memory session store and never touches WhatsApp Web internals, so the id rename can't reach it. A Baileys session with no chats returns an empty list with HTTP 200, not a 500 — different failure, different cause.

Could you open a separate issue with your OpenWA version, engine config, and the server logs from a failing request? I don't want it buried under this one, and I'd rather track it properly.

Closing as fixed in v0.8.18. Duplicate of #757.

[rmyndharis]

Correction on the upgrade command above — docker compose pull alone won't do it, sorry.

The docker-compose.yml in this repo builds the openwa service from source rather than pulling a published image (the only image: entries are Postgres, Redis, MinIO, and the socket proxy). So docker compose pull updates those side services and reports nothing to do for OpenWA itself, leaving you on v0.8.17 — you'd see the same 500 and reasonably conclude the fix didn't work.

If you're using the repo's docker-compose.yml (build from source):

git pull
docker compose up -d --build

The rebuild matters specifically here: the whatsapp-web.js patch is applied to the installed dependency during the image build, so a fresh build is what actually picks the fix up.

If your compose file points at the published image instead (image: ghcr.io/rmyndharis/openwa:latest), then docker compose pull && docker compose up -d is correct as originally written.

To confirm which version you actually end up on:

curl -s localhost:2785/api/health | grep -o '"version":"[^"]*"'

You want 0.8.18. Reopen if the 500 survives a confirmed 0.8.18.