Skip to content

[WEBJS] - GET /api/:session/chats/:chatId/messages returns HTTP 500 for some @lid chats with "Cannot read properties of undefined (reading 't')" #1985

@gsx1000rr

Description

@gsx1000rr

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.

patron:PLUS

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions