Describe the bug
On WEBJS, GET /api/:session/chats/:chatId/messages sometimes returns HTTP 500 for specific @lid chats even when the session is still connected/WORKING.
This is not a general session outage:
- the same session can still work for many other chats
- the same
@lid chat IDs fail repeatedly across many runs
- the session remains connected/WORKING, but these repeated per-chat failures make history/message fetching unreliable
Version
{
"version": "2026.3.2",
"engine": "WEBJS",
"tier": "PLUS"
}
Steps
To Reproduce Steps to reproduce the behavior:
Use a WEBJS session that is connected/WORKING.
Call GET /api/:session/chats/:chatId/messages for an @lid chat.
Use normal query params such as:
limit=30
merge=true
downloadMedia=false
sortBy=timestamp
filter.timestamp.gte=...
filter.timestamp.lte=...
offset=0
For some specific @lid chats, the endpoint returns HTTP 500.
Repeating the same request on the same chats fails again across many runs, while other chats on the same session still work.
Expected behavior
The endpoint should return messages or an empty result.
A single malformed or partially-loaded message should not crash the whole endpoint with HTTP 500.
Requests - Responses
Example request:
GET /api//chats/@lid/messages?limit=30&merge=true&downloadMedia=false&sortBy=timestamp&filter.timestamp.gte=&filter.timestamp.lte=&offset=0
Example response from logs:
{
"statusCode": 500,
"timestamp": "2026-03-19T17:00:39.160Z",
"exception": {
"message": "Cannot read properties of undefined (reading 't')",
"name": "TypeError",
"stack": "TypeError: Cannot read properties of undefined (reading 't')\n at evaluate (evaluate at WPage.evaluate (/app/dist/core/engines/webjs/WPage.js:13:36), :33:29)\n at #evaluate (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/ExecutionContext.js:391:56)\n at async ExecutionContext.evaluate (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/ExecutionContext.js:277:16)\n at async IsolatedWorld.evaluate (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/IsolatedWorld.js💯16)\n at async CdpFrame.evaluate (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/api/Frame.js:362:20)\n at async CdpPage.evaluate (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/api/Page.js:818:20)\n at async WPage.evaluate (/app/dist/core/engines/webjs/WPage.js:13:20)\n at async WebjsClientPlus.getMessages (/app/dist/core/engines/webjs/WebjsClientCore.js:171:26)\n at async WhatsappSessionWebJSPlus.getChatMessages (/app/dist/core/engines/webjs/session.webjs.core.js:597:26)"
}
}
Repeated failures are concentrated on the same @lid chats.
Examples:
Session 664
135656709836928@lid -> 71x
161134304862238@lid -> 70x
135227364114451@lid -> 69x
146922308374667@lid -> 67x
Session 1011
8633538609331@lid -> 178x
160795656720462@lid -> 145x
57793784619244@lid -> 72x
173568486834325@lid -> 72x
The session itself remains connected/WORKING while the same @lid chats keep failing.
Additional context
From the WAHA WEBJS implementation, getMessages() appears to directly access message fields such as m.t, m.id.fromMe, and earliest.t without defensive checks.
Because of that, one malformed/partial message object may be able to crash the whole endpoint instead of being skipped safely.

Describe the bug
On WEBJS,
GET /api/:session/chats/:chatId/messagessometimes returns HTTP 500 for specific@lidchats even when the session is still connected/WORKING.This is not a general session outage:
@lidchat IDs fail repeatedly across many runsVersion
{
"version": "2026.3.2",
"engine": "WEBJS",
"tier": "PLUS"
}
Steps
To Reproduce Steps to reproduce the behavior:
Use a WEBJS session that is connected/WORKING.
Call GET /api/:session/chats/:chatId/messages for an @lid chat.
Use normal query params such as:
limit=30
merge=true
downloadMedia=false
sortBy=timestamp
filter.timestamp.gte=...
filter.timestamp.lte=...
offset=0
For some specific @lid chats, the endpoint returns HTTP 500.
Repeating the same request on the same chats fails again across many runs, while other chats on the same session still work.
Expected behavior
The endpoint should return messages or an empty result.
A single malformed or partially-loaded message should not crash the whole endpoint with HTTP 500.
Requests - Responses
Example request:
GET /api//chats/@lid/messages?limit=30&merge=true&downloadMedia=false&sortBy=timestamp&filter.timestamp.gte=&filter.timestamp.lte=&offset=0
Example response from logs:
{
"statusCode": 500,
"timestamp": "2026-03-19T17:00:39.160Z",
"exception": {
"message": "Cannot read properties of undefined (reading 't')",
"name": "TypeError",
"stack": "TypeError: Cannot read properties of undefined (reading 't')\n at evaluate (evaluate at WPage.evaluate (/app/dist/core/engines/webjs/WPage.js:13:36), :33:29)\n at #evaluate (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/ExecutionContext.js:391:56)\n at async ExecutionContext.evaluate (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/ExecutionContext.js:277:16)\n at async IsolatedWorld.evaluate (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/IsolatedWorld.js💯16)\n at async CdpFrame.evaluate (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/api/Frame.js:362:20)\n at async CdpPage.evaluate (/app/node_modules/puppeteer-core/lib/cjs/puppeteer/api/Page.js:818:20)\n at async WPage.evaluate (/app/dist/core/engines/webjs/WPage.js:13:20)\n at async WebjsClientPlus.getMessages (/app/dist/core/engines/webjs/WebjsClientCore.js:171:26)\n at async WhatsappSessionWebJSPlus.getChatMessages (/app/dist/core/engines/webjs/session.webjs.core.js:597:26)"
}
}
Repeated failures are concentrated on the same @lid chats.
Examples:
Session 664
135656709836928@lid -> 71x
161134304862238@lid -> 70x
135227364114451@lid -> 69x
146922308374667@lid -> 67x
Session 1011
8633538609331@lid -> 178x
160795656720462@lid -> 145x
57793784619244@lid -> 72x
173568486834325@lid -> 72x
The session itself remains connected/WORKING while the same @lid chats keep failing.
Additional context
From the WAHA WEBJS implementation, getMessages() appears to directly access message fields such as m.t, m.id.fromMe, and earliest.t without defensive checks.
Because of that, one malformed/partial message object may be able to crash the whole endpoint instead of being skipped safely.