Discord Channels Lag

[scenic oak]

I’m wondering if this is a bug with my system or because of a recent update. When I send a message on a channel that is routed to my main agent, I get the typing indicator almost right away. On other channels that are routed to agents other than my main agent, there is a solid seven seconds gap between me sending the message and the typing indicator appearing.

[grand phoenix]

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

[mighty idol]

First thing: can you paste openclaw --version? Version matters here because typing behavior has changed recently.

I checked the current docs/source. A ~6-7s delay lines up suspiciously well with the typing config defaults/cadence, not necessarily Discord lag. Typing has modes:

• instant: starts when the model loop begins
• message: waits until the first real text delta
• thinking: waits for streamed reasoning
• never: disabled

Docs: https://docs.openclaw.ai/concepts/typing-indicators

The default behavior is immediate for DMs/mentions, but group-channel/unmentioned runs can wait for message text. If your main agent/channel feels instant while routed secondary agents lag, I’d check whether those routed sessions/agents are resolving to message or thinking instead of instant.

Try setting the default explicitly:

[mighty idol]

{
  agents: {
    defaults: {
      typingMode: "instant",
      typingIntervalSeconds: 6,
    },
  },
}

Then restart the gateway and compare the same channel again. Config ref: https://docs.openclaw.ai/gateway/configuration-reference#typing-indicators

If it still takes ~7s with typingMode: "instant", that points more toward routing/session startup latency for non-main agents, and I’d file it as a GitHub issue with version, config shape for the bindings/agents, and a short gateway log excerpt around the inbound message: https://github.com/openclaw/openclaw/issues

[scenic oak]

Currently I’m running OpenClaw 2026.5.7 but I started experiencing this since a few versions before. Agents.defaults.typingMode is currently set to “instant”.

[mighty idol]

Thanks, that’s useful. With agents.defaults.typingMode: "instant", the typing indicator should fire at run start before preflight compaction/memory work. So if the delay is still before typing appears, it’s probably happening earlier: routing to the non-main agent, loading that agent’s session store/runtime config, queue/run setup, or Discord delivery of the typing event.

A few focused checks:

openclaw status --all
openclaw logs --follow

Then send one message to the fast main-agent channel and one to a slow routed-agent channel. In the logs, compare the timestamp gap between inbound Discord receipt/routing and the first run/typing-related line.

Also check whether the delay is:

• only the first message after gateway restart: likely cold load for that agent
• every message in that routed channel: more likely a routing/session-store bug or blocked queue
• only one secondary agent: inspect that agent’s session store under ~/.openclaw/agents/<agentId>/sessions/sessions.json for huge/stale state

Docs for the relevant pieces:

[mighty idol]

https://docs.openclaw.ai/concepts/typing-indicators
https://docs.openclaw.ai/channels/channel-routing
https://docs.openclaw.ai/help/faq#first-60-seconds-if-something-is-broken

Given your version and explicit instant, I’d lean “possible bug / performance regression” rather than config. If you can reproduce it consistently, file an issue with the version, your sanitized bindings / agents.list shape, whether it happens on first vs every message, and the log timestamp gap: https://github.com/openclaw/openclaw/issues

[scenic oak]

Working with my system agent:

I checked our side:

• typingMode is definitely "instant".
• Gateway/channels are healthy overall.
• Secondary agent session stores are not absurdly huge:
  • George: 862 KB, 36 sessions
  • Alex: 226 KB, 14 sessions
  • Main is actually bigger: 2.4 MB, 119 sessions

So I wouldn’t blame a giant session store.

The suspicious bit: status logs show repeated liveness/queue warnings involving George, including a stale queued George WhatsApp item and George Discord sometimes sitting with q=1. That lines up more with routing/queue/run setup delay before typing fires, not compaction/memory.

There’s also a recurring secrets.resolve failed for Google webSearch, but I don’t think that explains the 7-second pre-typing lag. Worth fixing separately, not the main suspect.

[mighty idol]

Yep, I agree with your system agent’s read. The queue warnings are more interesting than session-store size.

One important nuance from the queue docs/source: typingMode: "instant" starts typing when a run actually starts. If the inbound message is classified as a followup because that session/agent already has an active/stale run, it can sit queued first; in that state you may see q=1 and no typing yet. So a stale George item can absolutely explain “delay before typing,” even with instant typing configured.

I’d try this in the affected George-routed Discord thread/channel:

/stop

That path is supposed to abort the active target session and clear queued followups. Then send a normal test message right after and watch whether the 7s gap disappears.

If q=1 comes back or survives /stop, I’d capture:

• the exact q=1 / stale queued log lines
• whether the queued item is same session key or just same agent
• messages.queue config, if customized

[mighty idol]

• agents.defaults.maxConcurrent
• sanitized bindings for George/Alex/main

Queue docs: https://docs.openclaw.ai/concepts/queue

The Google secrets.resolve failed for webSearch is probably separate, agreed. Fix it, but I wouldn’t chase it for this pre-typing lag unless logs show it happening before every George run starts.

If /stop clears it only temporarily, that’s a pretty solid GitHub issue: “stale queued followup blocks routed secondary agent before typing indicator.” https://github.com/openclaw/openclaw/issues

[scenic oak]

I will try what you just said next, but after completing the test like you said earlier while trailing logs:

I caught the test, but the normal gateway logs are too quiet for exact inbound → typing timestamps. They didn’t log the Discord message receipt or typing event.

What I did find is useful:

• During your test window, logs showed no giant session-store read issue.
• There is a persistent stale queue item:
  • agent:george:whatsapp:group:...
  • sitting queued/idle for 22,000+ seconds
• The gateway also repeatedly reports event-loop delay, and George routed Discord runs often show:
  • processing ... q=1
  • sometimes still “processing” after run:completed for 7–13s
• That matches your symptom: the delay is likely in OpenClaw’s routing/queue bookkeeping for non-main agents before typing is emitted, not the typingMode config.

So for the help bot / GitHub issue, I’d say:

Repro: agents.defaults.typingMode = "instant" but routed Discord channels bound to non-main agents show ~7–11s delay before typing indicator appears. Main agent channel is faster. Session stores are not huge: George sessions.json ~862KB / 36 sessions, Alex ~226KB / 14 sessions. Status logs show repeated liveness warnings and stale queued work for agent:george:whatsapp:group:..., plus routed George Discord work sometimes remains processing q=1 after run:completed for several seconds. Normal gateway logs do not emit inbound/typing timestamps, so exact receipt→typing gap isn’t visible at default verbosity.

[mighty idol]

That’s a good capture. I’d file this as a queue/liveness bug, not a typing config issue.

Suggested issue title:

Routed non-main Discord agents delay typing indicator when stale queue item exists

Suggested body:

OpenClaw version: 2026.5.7
Config: agents.defaults.typingMode = "instant"

Symptom:
Discord channels routed to non-main agents show ~7-11s delay before the typing indicator appears. A Discord channel routed to the main agent shows typing much faster.

[mighty idol]

What was ruled out:
- typingMode is explicitly "instant"
- gateway/channels are generally healthy
- secondary agent session stores are not huge:
  - George sessions.json ~862 KB / 36 sessions
  - Alex sessions.json ~226 KB / 14 sessions
  - main is larger at ~2.4 MB / 119 sessions

Suspicious logs/state:
- persistent stale queued item:
  - agent:george:whatsapp:group:...
  - queued/idle for 22,000+ seconds
- repeated liveness/queue warnings involving George
- George-routed Discord runs often show processing ... q=1

[mighty idol]

- sometimes still shown as processing for 7-13s after run:completed
- normal gateway logs do not emit exact Discord inbound receipt or typing-event timestamps, so receipt -> typing delay is hard to measure at default verbosity

Expected:
With typingMode="instant", typing should be emitted as soon as the routed run begins, and stale queued work from another George session/channel should not cause a multi-second pre-typing delay for Discord routed to George.

Actual:
Typing appears delayed only for routed non-main agents, apparently correlated with stale queue/liveness state.

Before filing, I’d still try /stop in the affected George-routed conversation. If that clears the stale queue and the typing delay disappears, include that result. If it comes back later, that’s even better evidence: /stop temporarily clears it, but stale queue state reappears.

The event-loop delay warning is also worth including. It may be cause or collateral damage, but it explains why bookkeeping can lag after run:completed.

[scenic oak]

Got it — and this is actually strong evidence.

Right after your /stop + test in #station, the log still showed:

• active=agent:george:discord:channel:1486566189055344710(processing,q=1,age=9s last=run:completed)
• plus the old stale George WhatsApp queue item:
  • queued=agent:george:whatsapp:group:...(idle,q=1,age=23213s last=run:completed)

So /stop did not cleanly clear the George Discord queued/processing state. It was still marked processing,q=1 9 seconds after run:completed, which matches your ~7–11 sec delay almost perfectly.

That’s the bug shape:

Routed secondary agent session remains in processing,q=1 after run completion, causing followup messages to queue before typing starts, even with typingMode: instant. /stop does not fully clear the stale queued/processing state.

I’d give that exact line to the help bot / GitHub issue. The channel key is same as affected channel: agent:george:discord:channel:1486566189055344710, so this is not just “same agent somewhere else” — it’s the same George Discord session.

[mighty idol]

Yep, that nails it down. The key detail is that the affected Discord session itself stays in:

agent:george:discord:channel:1486566189055344710(processing,q=1,age=9s last=run:completed)

after completion. That explains why typingMode: "instant" doesn’t help: the next message is being treated as queued/followup before the new run reaches the point where instant typing can fire.

I’d file the issue with this tighter wording:

Bug: routed non-main Discord session remains processing,q=1 after run:completed, delaying typing

OpenClaw: 2026.5.7
Config: agents.defaults.typingMode = "instant"

[mighty idol]

A Discord channel routed to a non-main agent remains marked active/processing after the run completes:

agent:george:discord:channel:1486566189055344710(processing,q=1,age=9s last=run:completed)

During that window, followup messages appear to queue before typing starts, producing a visible ~7-11s delay before Discord typing appears. The main-agent routed channel does not show the same delay.

Tried /stop in the affected channel, but it did not fully clear the queued/processing state. The same George Discord session still showed processing,q=1 after run:completed.

There is also an older stale queue item for another George session:
agent:george:whatsapp:group:...(idle,q=1,age=23213s last=run:completed)

Session stores are not large:
George ~862 KB / 36 sessions
Alex ~226 KB / 14 sessions
Main ~2.4 MB / 119 sessions

[mighty idol]

Expected:
After run:completed, the routed Discord session should clear active/processing state promptly, and /stop should clear queued/processing state for the target session.

Short-term workaround: a gateway restart may clear the in-memory queue state, but if it comes back, the issue above is the useful artifact. https://github.com/openclaw/openclaw/issues

[scenic oak]

https://github.com/openclaw/openclaw/issues/81978

[mighty idol]

Perfect, thanks for filing it. That issue has the right shape now: same affected session key, processing,q=1 after run:completed, /stop not clearing it, and typingMode: "instant" ruled out.

If you get one more data point later, the most useful add-on would be whether a full gateway restart clears it temporarily and whether the stale q=1 state returns after a specific kind of run or channel switch.

[scenic oak]

That’s was the first thing I tried, and several times at that.

[mighty idol]

Ah, important correction then: if multiple full gateway restarts didn’t clear it, this is less likely to be only in-memory queue state.

I’d add that to the issue explicitly:

Additional data point: full gateway restart has been tried several times and does not clear the delayed typing / processing,q=1 behavior. So this does not appear to be a transient in-memory queue state that restart resolves.

That pushes suspicion toward state being reconstructed from persisted session/run metadata, or the completion cleanup path consistently leaving the routed session in that state. The issue is stronger with that note.

[scenic oak]

We tried it again just to be safe:

Confirmed: restart did not clear it.

Evidence after restart:

• You saw ~12s delay.
• Logs immediately showed the same #station George session:
  • active=agent:george:discord:channel:1486566189055344710(processing,q=1,age=2s)
  • queued=agent:george:discord:channel:1486566189055344710(processing,q=1,age=2s)

So it reproduces right away after restart — not just an old stale in-memory queue surviving.

I added that datapoint to the GitHub issue here:
https://github.com/openclaw/openclaw/issues/81978#issuecomment-4456114456

[mighty idol]

That’s the right datapoint to add. Since it reappears immediately after restart with both active and queued on the same session key, it’s almost certainly being recreated during normal routed run setup/cleanup rather than being old queue residue.

At this point I’d leave the issue focused and avoid adding more speculation unless you catch a narrower trigger. The strongest facts are: typingMode: instant, same George Discord session key, restart does not clear, and processing,q=1 appears immediately while typing is delayed.

[scenic oak]

Thanks