#Bug: message action=read on Discord returns TypeError: (intermediate value).map is not a function

1 messages · Page 1 of 1 (latest)

velvet birch
#

When the agent tries to read channel history via the message tool (action=read, channel=discord), it fails with:
Copier
TypeError: (intermediate value).map is not a function
This makes it impossible for the agent to load conversation history in Discord sessions, so it starts every interaction without any prior context.
Same issue appears with action=channel-list — the response comes back as raw gzip binary instead of parsed JSON.
Steps to reproduce:
Version: OpenClaw 2026.5.7, macOS arm64
Any idea if this is a known issue or a misconfiguration on my end? 🦞

coral sableBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

sacred boughBOT
#

This looks like a real Discord REST response parsing bug, not a normal Discord permission/config issue.

The giveaway is channel-list returning gzip-looking binary too. message read then tries to do .map(...) on whatever came back from the REST client; if the body is still a compressed/binary string instead of parsed JSON, you get exactly TypeError: (intermediate value).map is not a function.

There’s already a matching GitHub issue here: https://github.com/openclaw/openclaw/issues/80764

Things I’d check/attach there:

  • openclaw --version
  • node --version — if you’re on Node 26, try Node 22 LTS as a workaround/test
  • openclaw status --all
  • a short log excerpt around the failed message action=read

Also make sure the bot has Read Message History and View Channels, but given the raw gzip symptom I’d treat this as a client-side decode/shape-guard bug rather than misconfiguration. Docs for the Discord permission baseline: https://docs.openclaw.ai/channels/discord 🦞

velvet birch
#

I am running node 26

sacred boughBOT
#

Yep — that lines up with the known report. Node 26 is the suspicious part here.

OpenClaw is currently safest on Node 22 LTS. I’d switch the OpenClaw runtime/service to Node 22, reinstall/restart the gateway under that Node, then retry message(action=read) / channel-list.

If you use nvm, the important bit is that the background gateway must actually be launched from Node 22 too — not just your interactive shell. Rough shape:

nvm install 22
nvm use 22
npm install -g openclaw@latest
openclaw gateway restart
openclaw status --all

If it still reproduces on Node 22, please add that to the GitHub issue because then it’s not just a Node 26 fetch/decompression edge case: https://github.com/openclaw/openclaw/issues/80764

velvet birch
#

pdate: Reproduced on Node 22 LTS as well — so it's not a Node 26-specific issue.
Switched the gateway to Node 22 (/opt/homebrew/opt/node@22/bin/node) and reinstalled OpenClaw, but message action=read still returns:
Copier
TypeError: (intermediate value).map is not a function
Same for channel-list — raw gzip binary instead of parsed JSON.
Added to the GitHub issue: https://github.com/openclaw/openclaw/issues/80764

sacred boughBOT
#

Thanks for confirming — that pretty much rules out the Node 26 theory.

At this point I’d call it a real OpenClaw Discord REST decode bug, not your config. If both read and channel-list are returning raw gzip-ish bytes, permissions/pairing aren’t the cause; the REST client is receiving compressed Discord API bodies and handing them upward before JSON parsing.

Good add to the issue. The useful fix is likely in the Discord REST response path: detect/decompress gzip before JSON.parse, plus add shape guards so readMessages fails with “expected array, got string” instead of the confusing .map is not a function.

No good config workaround comes to mind besides avoiding those Discord history/list actions until patched. Your repro on Node 22 LTS is exactly the data maintainers need. 🦞

velvet birch
#

Any clue when this is going to be fixed ?