openclaw - 💡(How to fix) Fix [Bug]: Telegram forum topics serialize one-at-a-time despite agents.defaults.maxConcurrent=4

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

OpenClaw 2026.5.12 Telegram forum topics appear serialized despite agents.defaults.maxConcurrent=4.

Environment:

• OpenClaw 2026.5.12 f066dd2
• Telegram polling channel
• One Telegram supergroup with forum topics
• Model: minimax/MiniMax-M2.7
• agents.defaults.maxConcurrent=4
• agents.defaults.subagents.maxConcurrent=8
• systemd CPU/memory caps removed
• Gateway health OK
• Telegram ingress OK

Expected: Different Telegram forum topics should be separate sessions and should run in parallel up to agents.defaults.maxConcurrent. Docs say each session queues into the global main lane and Telegram topics use per-chat/per-topic bot lanes. Overall runner sink concurrency should use agents.defaults.maxConcurrent.

Actual: Multiple Telegram topic messages arrive, but processing behaves one-at-a-time. Live monitor shows inbound messages from topic:1, topic:4, topic:6, topic:3487, etc., but no evidence of active=2/3/4 model work. Earlier snapshots showed active=1 queued=1 and staggered sequential completions.

Evidence:

• Config confirms agents.defaults.maxConcurrent=4 and subagents.maxConcurrent=8.
• Systemd CPU/memory caps removed.
• Logs show multiple inbound Telegram topic messages.
• Runtime never shows multiple topic model calls active concurrently.
• Heavy topic blocks other topics; /stop feels non-preemptive because it appears queued behind active work.

Impact: Telegram forum topics cannot be used as parallel operator lanes. One heavy topic blocks the rest.

Steps to reproduce

1. Run OpenClaw 2026.5.12 with Telegram polling enabled against a Telegram supergroup with forum topics.

2. Configure the agent with:

   • agents.defaults.maxConcurrent = 4
   • agents.defaults.subagents.maxConcurrent = 8
   • channels.telegram.groups.<group_id>.requireMention = false

3. Confirm gateway health is OK:

   • openclaw config validate
   • openclaw gateway status --require-rpc
   • openclaw channels status --probe
   • openclaw status --deep

4. Send the same prompt to 4+ different Telegram forum topics in the same supergroup at roughly the same time.

5. Watch gateway logs with: journalctl --user -u openclaw-gateway.service --since '10 minutes ago' --no-pager -o cat
   | grep -Ei 'Inbound message telegram:group:|active=|queued=|waiting=|processing/model_call|run:completed|sendMessage ok|stalled session|context-overflow|compaction'

6. Direct observation:

   • inbound messages are logged from multiple different topic IDs
   • only one topic appears to run at a time
   • no active=2, active=3, or active=4 evidence appears
   • replies complete in a staggered/serial pattern
   • a heavy topic can block other topic replies

Expected behavior

Different Telegram forum topics should be separate sessions and should run in parallel up to agents.defaults.maxConcurrent.

Grounding:

• OpenClaw queue docs state that each session has its own session lane, then each session run enters the global main lane, and overall parallelism is capped by agents.defaults.maxConcurrent.
• OpenClaw Telegram docs state that each forum topic gets its own session key, and overall runner sink concurrency uses agents.defaults.maxConcurrent.

With agents.defaults.maxConcurrent=4, sending prompts to 4 different Telegram forum topics should show concurrent processing, such as active=2, active=3, or active=4, and replies should overlap rather than complete strictly one-at-a-time.

Actual behavior

Multiple Telegram forum-topic messages are accepted by the gateway, but the resulting agent work is observed to run one topic at a time instead of concurrently.

Observed result:

• I sent prompts to multiple different forum topics in the same Telegram supergroup at roughly the same time.
• Gateway logs showed inbound messages from multiple distinct topic IDs, including topic:1, topic:4, topic:6, topic:3487, and others.
• During the test, the live queue/status logs did not show active=2, active=3, or active=4.
• The observed queue evidence repeatedly showed only one active unit of work, for example active=1 / queued=1.
• Replies completed in a staggered sequence rather than overlapping.
• A heavy topic appeared to block other topics from replying.
• /stop also felt non-preemptive during the heavy run, consistent with control messages being queued behind normal work.

Relevant local evidence:

• OpenClaw version: 2026.5.12 f066dd2
• Config confirmed agents.defaults.maxConcurrent=4
• Config confirmed agents.defaults.subagents.maxConcurrent=8
• Systemd CPU/memory caps were removed before retesting
• Gateway health was OK
• Telegram ingress was OK
• Delivery queue was empty
• Topic sessions were separate session keys, but runtime behavior still appeared serialized

Example observed log pattern:

• Inbound message telegram:group:<group_id>:topic:1
• Inbound message telegram:group:<group_id>:topic:4
• Inbound message telegram:group:<group_id>:topic:6
• Inbound message telegram:group:<group_id>:topic:3487
• No matching active=2/3/4 model-call evidence during the same window
• Prior snapshots showed active=1 queued=1

User-visible impact: Telegram forum topics cannot currently be used as parallel operator lanes on this gateway. One long or heavy topic can delay replies in other topics even though agents.defaults.maxConcurrent is set to 4.

OpenClaw version

2026.5.12

Operating system

Ubuntu 24.04

Install method

npm global

Model

minimax

Provider / routing chain

Telegram supergroup forum topics → OpenClaw Telegram polling channel → OpenClaw gateway reply pipeline → per-topic Telegram session key, e.g. agent:main:telegram:group:<group_id>:topic:<topic_id> → per-session queue lane → global main lane → MiniMax provider route → minimax/MiniMax-M2.7 via https://api.minimax.io/anthropic using anthropic-messages API → OpenClaw Telegram delivery back to the same group/topic thread Observed provider/model config: - Primary model: minimax/MiniMax-M2.7 - Fallbacks: none - Model transport: auto - Provider API style: anthropic-messages - Telegram mode: polling - Gateway mode: local loopback, systemd user service - Telegram delivery: same bot account back into the original forum topic Relevant docs: OpenClaw queue docs say session runs enter the global main lane and overall parallelism is capped by agents.defaults.maxConcurrent. OpenClaw Telegram docs say forum topics use per-topic session keys and overall runner sink concurrency uses agents.defaults.maxConcurrent.

Additional provider/model setup details

No response

Logs, screenshots, and evidence

No API keys, bot tokens, gateway tokens, or passwords included here.

OpenClaw install/runtime:
- OpenClaw version: 2026.5.12 f066dd2
- Gateway process: systemd user service
- Gateway bind: loopback / local mode
- Gateway port: 18789
- Telegram channel mode: polling
- Telegram group mode: allowlist
- Telegram forum topics enabled
- requireMention: false for the tested group
- Telegram streaming: off
- Telegram textChunkLimit: 3000

Agent/model setup:
- Agent: main
- Primary model: minimax/MiniMax-M2.7
- Fallbacks: []
- Configured models after cleanup:
  - minimax/MiniMax-M2.7
  - openai-codex/gpt-5.5
- Plain openai/gpt-5.5 was removed from selectable models after the 5.12 update rewrote config
- MiniMax model route uses provider id: minimax
- MiniMax base URL: https://api.minimax.io/anthropic
- MiniMax API mode: anthropic-messages
- MiniMax transport: auto
- MiniMax contextWindow: 204800
- MiniMax maxTokens: 131072

Auth/profile setup:
- MiniMax key is supplied via environment/config interpolation, not pasted into the issue.
- OpenAI Codex auth profile exists for openai-codex/gpt-5.5 via OAuth.
- OpenAI API key exists in service environment for memory embeddings and OpenAI provider availability.
- No model fallback was active during the Telegram topic parallelism tests; primary MiniMax was the effective route.

Concurrency setup:
- agents.defaults.maxConcurrent = 4
- agents.defaults.subagents.maxConcurrent = 8
- No root-level legacy concurrency object is present after cleanup.
- messages.queue is not explicitly configured.
- root queue config is not explicitly configured.
- Systemd CPU/memory caps were removed before retesting:
  - CPUQuotaPerSecUSec = infinity
  - MemoryHigh = infinity
  - MemoryMax = infinity
  - MemorySwapMax = infinity
- OpenClaw health after restart was OK.

Memory/context setup:
- memory-core plugin enabled.
- Active-memory plugin was not enabled during this test.
- Topic 1 hit context overflow and auto-compaction during one stress test, but serialization was also observed across multiple topic tests.
- The observed issue is not limited to a single stale session; separate Telegram forum topics had separate session keys.

Why this matters for routing:
OpenClaw docs describe session runs as entering a per-session lane, then the global main lane, where overall parallelism should be capped by agents.defaults.maxConcurrent. OpenClaw Telegram docs describe forum topics as isolated per-topic sessions, with overall runner sink concurrency using agents.defaults.maxConcurrent. In this setup, those docs imply different forum topics should be able to run concurrently up to the configured cap, but observed behavior remained one-at-a-time.

Impact and severity

Affected users/systems/channels:

• Affects this OpenClaw 2026.5.12 gateway when using Telegram polling with one Telegram supergroup and multiple forum topics.
• Affects Telegram forum-topic operator workflows where different topics are expected to act as independent working lanes.
• Observed with the main agent using minimax/MiniMax-M2.7.
• Not observed as a general Telegram transport outage: inbound messages were accepted, gateway health was OK, Telegram channel health was OK, and delivery worked for short/simple messages.

Severity:

• Blocks workflow for multi-topic Telegram operations.
• This is more than annoying because one long/heavy topic can delay or block replies in other topics.
• It creates operator uncertainty: the UI shows “typing…”/pending behavior, but other topics do not appear to progress concurrently.
• No data loss was directly observed.
• No secret exposure or file corruption was observed.
• No confirmed financial/data-risk impact was observed from this issue alone.

Frequency:

• Reproduced during simultaneous multi-topic tests.
• When sending prompts to several forum topics at roughly the same time, observed behavior was effectively one-at-a-time rather than parallel.
• Single-topic / one-at-a-time prompts worked normally.
• Short Telegram sends and smoke tests worked normally.
• The issue appears tied to concurrent forum-topic workload, especially when one topic is heavy or hits compaction/context pressure.

Consequence:

• Telegram forum topics cannot currently be relied on as parallel operator lanes on this gateway.
• A heavy topic can delay other topic replies.
• /stop can feel non-preemptive because it appears to wait behind active work.
• This increases manual monitoring and retry work for the operator.
• It reduces the usefulness of Telegram forum topics for running multiple OpenClaw workstreams in parallel.
• It may increase latency and confusion during operational/debug sessions, because messages are accepted but replies appear serialized or delayed.

Additional information

Regression / version context:

• Last known good version: NOT_ENOUGH_INFO
• First known bad version from direct observation: OpenClaw 2026.5.12 f066dd2
• Similar one-at-a-time / bottleneck behavior was suspected during earlier 2026.5.7 testing, but the strongest grounded reproduction and clean config evidence are from 2026.5.12.
• I cannot claim a known-good OpenClaw version for this exact Telegram forum-topic parallelism behavior from direct evidence.

Useful triage context:

• The issue was investigated after upgrading to 2026.5.12 and cleaning old sessions/orphans.
• A config drift from the updater was corrected before the final test:
  • agents.defaults.maxConcurrent = 4
  • agents.defaults.subagents.maxConcurrent = 8
  • legacy root-level concurrency = null
• After that correction, gateway health was OK and event loop health was OK.
• Systemd CPU/memory caps were removed before the final reproduction:
  • CPUQuotaPerSecUSec = infinity
  • MemoryHigh = infinity
  • MemoryMax = infinity
  • MemorySwapMax = infinity
• Telegram network workaround was removed before final native testing; the final config did not rely on NODE_OPTIONS=--dns-result-order=ipv4first.
• Telegram transport was not failing in the final test:
  • inbound forum-topic messages were logged
  • Telegram channel health was OK
  • delivery queue was empty
  • short/simple messages and DM smoke tests worked
• The practical issue is not “Telegram cannot send”; it is that multiple forum topics do not appear to execute concurrently.

Observed queue/source-code context from local install:

• Local installed queue docs/source indicate unconfigured lanes default to concurrency 1.
• Local installed source includes a code path intended to set the main lane concurrency from agents.defaults.maxConcurrent.
• Despite that, observed runtime behavior still looked like one active topic at a time.
• Live monitor after the corrected config still did not show active=2, active=3, or active=4 during simultaneous multi-topic prompts.
• The observed behavior matches a hidden serialization point somewhere before or inside the global main lane, or the main lane concurrency setter not being effective for Telegram forum-topic runs.

Related docs / references:

• OpenClaw queue docs say the default lane main is process-wide for inbound + main heartbeats and agents.defaults.maxConcurrent allows multiple sessions in parallel.
• OpenClaw Telegram docs say forum topics append :topic:<threadId> to keep topics isolated, and overall runner sink concurrency uses agents.defaults.maxConcurrent.
• There are existing/related GitHub issues and feature requests around Telegram or main-lane concurrency bottlenecks, including “Message Processing Bottleneck with Multiple Telegram Bots (main lane concurrency limit)” and “Feature Request: Parallel Session Processing.”