Post tool-call message not reaching Discord.

[lean raft]

I have a new issue where every message that comes directly after a series of tool calls does not reach Discord. I'm sitting there thinking the bot is "thinking" but in reality it has answered me and waiting. If I go to check, I can see the message in Dashboard Chat.

Normal assistant reply after tool use
generated through the usual assistant response path
this is the path that seems to get swallowed on Discord

Explicit channel message
sent via the messaging tool directly to the Discord channel
this is the path that reliably reaches you

My fragile workaround is to flag this issue in TOOLS.md and hope the bots remember to message me explicitly via the messaging tool directly to Discord.

[little ore]

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

[clever falcon]

That symptom usually means the Discord handler timed out / got aborted, so the agent run still finishes (=> you see the final answer in Dashboard Chat), but the Discord delivery step never runs (=> nothing posted in the thread).

In the Discord docs this is called out here: https://docs.openclaw.ai/channels/discord#long-running-handlers-time-out-or-duplicate-replies

1) Check logs for the smoking gun

When it happens, openclaw logs --follow and look for lines like:

• Listener DiscordMessageListener timed out after 30000ms for event MESSAGE_CREATE
• Slow listener detected ...
• discord inbound worker timed out after ...
• discord final reply failed: ...

If you paste the ~30 lines around that log, we can tell exactly which timeout you’re hitting.

2) Fix: raise the Discord timeouts (config)

Per docs, the knobs are:

• channels.discord.eventQueue.listenerTimeout (or channels.discord.accounts.<id>.eventQueue.listenerTimeout)
• channels.discord.inboundWorker.runTimeoutMs (or channels.discord.accounts.<id>.inboundWorker.runTimeoutMs)

Docs’ recommended baseline:

{
  channels: {
    discord: {
      accounts: {
        default: {
          eventQueue: { listenerTimeout: 120000 },
          inboundWorker: { runTimeoutMs: 1800000 }
        }
      }
    }

  }
}

3) Two quick questions (so we don’t guess)

1. What’s your openclaw --version?
2. Roughly how long are the “tool heavy” turns that cause the drop (30s+? minutes?) and do you have channels.discord.streaming enabled?

With those + the log snippet, we can narrow it down to either listener budget, inbound worker timeout, or an actual Discord send error.

[lean raft]

• Version: OpenClaw 2026.3.9
• Observed pattern: explicit message tool sends reach Discord reliably; normal post-tool assistant replies are the ones that sometimes go missing
• What user sees: reply shows in Dashboard Chat / internal session history, but not in Discord
• So scope seems to be: normal assistant-reply -> Discord delivery path, not Discord messaging generally
• Docs match this theory: DiscordMessageListener timed out after 30000ms, Slow listener detected, discord inbound worker timed out
• Historical evidence on this machine: we’ve previously seen Listener DiscordMessageListener timed out after 30000ms for event MESSAGE_CREATE
• Current ask: compare one missing post-tool reply event against one successful explicit message.send event around dispatch/delivery timing

[clever falcon]

Yep — with 2026.3.9 + “reply exists in Dashboard but never hits Discord”, the most likely explanation is still:

the Discord event handler timed out (30s listener budget), so the run finishes and writes to the session, but the delivery callback gets cut off.
Your manual message.send works because it’s a new inbound turn with a fresh listener window.

What to capture (so we can compare missing vs successful)

Repro once while tailing logs:

openclaw logs --follow --json

Then for the missing reply, grab the log block around the inbound Discord message and look specifically for any of these:

• Listener DiscordMessageListener timed out after 30000ms for event MESSAGE_CREATE
• Slow listener detected ...
• discord inbound worker timed out after ...

• discord final reply failed: ...

For the successful message.send, grab the outbound send log lines right after you trigger it.

If you paste:

1. the inbound Discord message id (snowflake) for the “missing” case, and
2. ~30-80 log lines around each case,
   we can tell whether it’s (A) timeout/abort (delivery never attempted) vs (B) outbound send error (delivery attempted, Discord rejected).

Config change to test immediately (timeout fix)

In Discord docs, the knob is eventQueue.listenerTimeout (and sometimes inboundWorker.runTimeoutMs).

Start with the doc baseline (multi-account form shown; adjust if you don’t use accounts):

{

  channels: {
    discord: {
      accounts: {
        default: {
          eventQueue: { listenerTimeout: 120000 },
          inboundWorker: { runTimeoutMs: 1800000 }
        }
      }
    }
  }
}

Docs reference: https://docs.openclaw.ai/channels/discord#long-running-handlers-time-out-or-duplicate-replies

If you apply that and the symptom disappears, we’ve basically confirmed the root cause is the 30s listener timeout path. If it doesn’t, the logs will usually show the exact outbound error (403/400/etc.) and we’ll chase that next.

[lean raft]

We have:

historical evidence that this machine has had the relevant timeout class
Listener DiscordMessageListener timed out after 30000ms for event MESSAGE_CREATE
current symptom evidence
missing normal post-tool replies in Discord
explicit message sends still arrive
docs that describe a matching failure mode

But we do not yet have a smoking-gun timeout log tied to one specific missing message event we observed today.

So the timeout theory is:
plausible
supported
but not yet directly nailed to a single concrete dropped reply instance in this session.

I will check out the docs and your config block as well as fish for more evidence.

[clever falcon]

Makes sense — you’ve got a strong circumstantial case, just not a message-id-linked log line yet.

Two concrete ways to “nail it” to one specific dropped reply on 2026.3.9:

1) Look for the worker timeout line that includes messageId

In 2026.3.9 the Discord inbound worker timeout log is formatted with channelId + messageId:

discord inbound worker timed out after … (channelId=…, messageId=…)

So next time you reproduce a missing reply:

1. Copy the Discord message id (Dev mode → right click message → Copy Message Link).
2. Run:

openclaw logs --follow --json

3. Search the output for that message id — if the worker timeout happened, it’ll include it explicitly.

This is the cleanest “smoking gun” because it ties the timeout directly to the exact inbound message that later had no outbound reply.

2) Verify you didn’t accidentally set a tiny worker timeout

Defaults in current code are listener: 120s and inbound worker: 30 minutes — so if you’re effectively seeing ~30s behavior, it’s almost certainly an override.

Check (and paste values, tokens redacted):

openclaw config get channels.discord.inboundWorker.runTimeoutMs
openclaw config get channels.discord.eventQueue.listenerTimeout
openclaw config get channels.discord.accounts.default.inboundWorker.runTimeoutMs
openclaw config get channels.discord.accounts.default.eventQueue.listenerTimeout

(Depending on whether you use accounts.)