Skip to content

[Bug]: [discord] DiscordMessageListener blocks event lane for full turn duration — stuck typing indicator + message queue buildup during long agentic turns #27690

Description

@i-am-rad

Summary

When an agent turn involves many sequential tool calls (e.g. screenshot → vision model → mouse click → repeat), DiscordMessageListener holds the Discord event lane open for the entire turn duration — observed up to 25 minutes. This causes a stuck "typing..." indicator in Discord, incoming messages backing up or dropping, EventQueue 30s timeouts firing repeatedly, and LLM turn timeouts triggering mid-tool-chain with blind retries.

Steps to reproduce

  1. Configure a Discord channel with typingMode: "message"
  2. Send a message that triggers a turn requiring 15+ sequential tool calls (e.g. any browser automation task with repeated screenshot + vision model loops)
  3. While the turn is running, send a follow-up message
  4. Observe typing indicator stuck, follow-up message queued/dropped, EventQueue timeouts firing

Expected behavior

  • Event lane is released after the turn is enqueued, not after it completes
  • Incoming messages during a long turn are acknowledged and processable
  • LLM timeout applies to model inference time, not cumulative tool execution time

Actual behavior

  • DiscordMessageListener holds the lane for the full turn wall-clock time
  • Typing indicator stays active for the entire duration (up to 25 min)
  • Queued messages trigger repeated EventQueue 30s timeouts with no user feedback
  • LLM 600s timeout fires against total turn time including tool calls, causing retry which also times out

OpenClaw version

2026.2.24

Operating system

macOS Darwin 24.6.0 (Mac mini 2018, Intel i3, 8GB RAM)

Install method

npm global (npm install -g openclaw)

Logs, screenshots, and evidence

~/.openclaw/logs/gateway.err.log — 2026-02-26:

Slow listener durations (single session):
[discord] Slow listener detected: DiscordMessageListener took 30.1 seconds for event MESSAGE_CREATE
[discord] Slow listener detected: DiscordMessageListener took 105.6 seconds for event MESSAGE_CREATE
[discord] Slow listener detected: DiscordMessageListener took 112.9 seconds for event MESSAGE_CREATE
[discord] Slow listener detected: DiscordMessageListener took 133.8 seconds for event MESSAGE_CREATE
[discord] Slow listener detected: DiscordMessageListener took 206 seconds for event MESSAGE_CREATE
[discord] Slow listener detected: DiscordMessageListener took 282.2 seconds for event MESSAGE_CREATE
[discord] Slow listener detected: DiscordMessageListener took 360.5 seconds for event MESSAGE_CREATE
[discord] Slow listener detected: DiscordMessageListener took 532.3 seconds for event MESSAGE_CREATE
[discord] Slow listener detected: DiscordMessageListener took 1509.6 seconds for event MESSAGE_CREATE


EventQueue timeouts (30s threshold, fired 7+ times):
[EventQueue] Listener DiscordMessageListener timed out after 30000ms for event MESSAGE_CREATE


Back-to-back LLM turn timeouts:
[agent/embedded] embedded run timeout: runId=9f6d55c7 timeoutMs=600000
[agent/embedded] Profile anthropic:default timed out. Trying next account...
[diagnostic] lane task error: error="FailoverError: LLM request timed out."
[agent/embedded] embedded run timeout: runId=9f6d55c7 timeoutMs=600000
[diagnostic] lane task error: error="FailoverError: LLM request timed out."

Impact and severity

Severity: Low
Frequency: Always — reproducible any time a turn exceeds ~2 minutes of tool execution
Workaround available? Yes — spawn long-running tool tasks as sub-agents so the main session event lane stays free

Additional information

Additional Information
Relevant config:
{
"agents": {
"defaults": {
"typingMode": "message",
"model": { "primary": "anthropic/claude-sonnet-4-6" }
}
}
}

The typingMode: "message" setting is correct behavior — the issue is not the typing indicator itself but that the event lane isn't released until the turn completes. Decoupling lane release from turn completion would fix the core issue. A separate maxTurnMs config (distinct from model inference timeout) would also help operators cap runaway turns gracefully.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingstaleMarked as stale due to inactivity

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions