#Discord “typing then no message” — context overflow during tool loop (compaction/retry)

1 messages · Page 1 of 1 (latest)

full crag
#

Seeing a recurring Discord failure mode and would love a sanity check.

Symptom (Discord only): bot starts typing, then typing stops, but no message is delivered (no visible error).

What the gateway log shows: this is not a Discord API send error — it’s an internal run failure before send:

The same log repeatedly shows workspace bootstrap injections being truncated for Discord runs (AGENTS.md, HEARTBEAT.md, MEMORY.md all > 12k chars), which likely contributes to hitting the overflow threshold once tool loops start producing large toolResults.

A session reset didn’t fully fix it: rotating Discord session .jsonl files helps, but overflow can still occur mid tool-loop even with “fresh-ish” session history.

Proposed low-risk fix (Discord-only): add a guild-level systemPrompt override to enforce “short replies first”, avoid dumping big logs/code/tool output into Discord, summarize + reference file paths, etc. (Goal: prevent tool-loop context blowups.)

Before I do that:

  1. Does this match a known Discord “typing then vanish” failure mode in OpenClaw?
  2. Is the systemPrompt mitigation the right lever, or is there a better schema-valid way to reduce injected context specifically for Discord (without impacting Telegram)?
  3. Anything else I should be searching for in logs to confirm the exact abort point?
stable flumeBOT
#

Yep — sanity check: this does fit the “typing then vanish” shape I’d expect when the Discord run dies internally before the channel send step. Typing is started while the agent run is active; if the run aborts on context overflow / compaction failure / provider prompt-size error before producing a final assistant message, Discord never sees a send error because no send was attempted.

A few concrete notes from the current docs/source:

  1. The bootstrap truncation lines are a signal, but not necessarily the direct cause. OpenClaw injects workspace bootstrap files into the system prompt and truncates large ones. Current docs show defaults around agents.defaults.bootstrapMaxChars and agents.defaults.bootstrapTotalMaxChars; /context is the quickest way to inspect raw vs injected sizes. Docs: https://docs.openclaw.ai/concepts/context

  2. A Discord channel-level systemPrompt is schema-valid and low risk for behavior shaping. Source has channels.discord.guilds.<guild>.channels.<channel>.systemPrompt, plus includeThreadStarter. So yes, a “short Discord replies, summarize logs, reference paths, don’t paste huge tool output” prompt is a reasonable mitigation.

  3. If the goal is to reduce injected context, though, systemPrompt is only an instruction; it won’t reduce bootstrap payload by itself. The more direct levers are agent-level/default context settings:

    • agents.defaults.contextInjection: "continuation-skip"
    • agents.defaults.bootstrapMaxChars
    • agents.defaults.bootstrapTotalMaxChars
    • possibly route Discord to a dedicated lighter agent with smaller bootstrap/context settings, leaving Telegram untouched

  4. Discord-specific/schema-valid knobs I’d consider before or alongside the prompt:

    • set the channel’s includeThreadStarter: false if thread starter context is bulky/repeated
    • limit channel skills if too many skills are being loaded into the prompt
#
  • use a dedicated Discord agent via routing/bindings if you need smaller bootstrap limits only for Discord

For confirming the exact abort point, search logs around one vanished turn for these strings:

context overflow detected
auto-compaction succeeded
auto-compaction failed
context overflow persisted
[context-overflow-precheck]
post-compaction tool-result truncation
branch=give_up
Request size exceeds
context length exceeded
maximum context length
prompt is too long