[Bug]: GET /channels/{channelId}/messages returns empty array [] (200 OK) for channels

[Header9968]

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

OpenWA v0.8.7

Deployment

Docker Compose

Database

SQLite (default)

WhatsApp engine

whatsapp-web.js

What happened?

Description

The endpoint GET /api/sessions/{sessionId}/channels/{channelId}/messages
returns an empty array [] with HTTP 200, even though the target channel
(newsletter) contains many messages. No error is thrown — the response is
simply empty.

Version

OpenWA v0.8.7

Steps to Reproduce

1. Have a session subscribed to a WhatsApp channel (newsletter).
2. Confirm the channel appears in GET /channels (it does, with correct name/id).
3. Confirm the channel has messages (visible in the WhatsApp app).
4. Call GET /api/sessions/{sessionId}/channels/{channelId}/messages
   with a valid X-API-Key.

Expected Behavior

The endpoint should return the list of channel messages
(as documented: "List of channel messages").

Actual Behavior

• Status: 200 OK
• Response body: []
• Response header: content-length: 2

The array is always empty regardless of limit value or channel.

Additional Context

• GET /channels works correctly and lists all subscribed channels.
• The same channel messages ARE retrievable through a different WhatsApp
  API gateway (Evolution API) using the same session/account, which
  suggests the messages exist and are accessible — the issue appears
  specific to this endpoint's implementation.
• Engine: whatsapp-web.js (default ENGINE_TYPE).

Environment

• OpenWA version: 0.8.7
• Engine: whatsapp-web.js
• Deployment: self-hosted (Docker / [укажите ваше])

Steps to reproduce

Description

The endpoint GET /api/sessions/{sessionId}/channels/{channelId}/messages
returns an empty array [] with HTTP 200, even though the target channel
(newsletter) contains many messages. No error is thrown — the response is
simply empty.

Version

OpenWA v0.8.7

Steps to Reproduce

1. Have a session subscribed to a WhatsApp channel (newsletter).
2. Confirm the channel appears in GET /channels (it does, with correct name/id).
3. Confirm the channel has messages (visible in the WhatsApp app).
4. Call GET /api/sessions/{sessionId}/channels/{channelId}/messages
   with a valid X-API-Key.

Expected Behavior

The endpoint should return the list of channel messages
(as documented: "List of channel messages").

Actual Behavior

• Status: 200 OK
• Response body: []
• Response header: content-length: 2

The array is always empty regardless of limit value or channel.

Additional Context

• GET /channels works correctly and lists all subscribed channels.
• The same channel messages ARE retrievable through a different WhatsApp
  API gateway (Evolution API) using the same session/account, which
  suggests the messages exist and are accessible — the issue appears
  specific to this endpoint's implementation.
• Engine: whatsapp-web.js (default ENGINE_TYPE).

Environment

• OpenWA version: 0.8.7
• Engine: whatsapp-web.js
• Deployment: self-hosted (Docker / [укажите ваше])

Expected behavior

No response

Relevant logs

Environment / additional context

No response

[Header9968]

Deployed via Portainer (Docker Compose stack).

[rmyndharis]

Thanks for the detailed report — that was enough to pin it down precisely.

Root cause: the whatsapp-web.js adapter resolved the channel with client.getChannelById(channelId), but whatsapp-web.js 1.34.x has no such method on its Client. The call threw at runtime and a try/catch swallowed the error into [] — which is exactly why you saw a 200 with an empty body and no error in the logs. GET /channels kept working because it uses a different (real) method, getChannels().

Fix (#629): channel messages are now read from the subscribed Channel instance via getChannels(), and the error is no longer swallowed. An unknown/unsubscribed channel id now returns a clear 404 instead of a silent empty 200.

One honest caveat: whatsapp-web.js reads channel messages from the session's local message store. This fix makes the endpoint return whatever the engine has actually synced, but for a channel that was just subscribed and whose history hasn't hydrated locally yet, the store can still be sparse. That's a separate engine-level limitation from the always-empty bug fixed here. If you still see fewer messages than expected after this ships, that's the area to look at next, and it'd help to know whether the messages arrive live (while the session is connected) versus only historically.

Will land on the next release.