openclaw - 💡(How to fix) Fix [Bug]: Telegram forum topic messages are serialized across topics before reaching agent pipeline

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading to OpenClaw 2026.5.12, Telegram forum-topic messages sent to different topics in the same group are processed sequentially before they reach the agent pipeline: topic B is not logged as inbound until immediately after topic A replies.

Steps to reproduce

1. Run OpenClaw 2026.5.12 with Telegram enabled and a Telegram forum/group containing at least two topics.
2. In topic A, send a prompt that triggers a normal agent reply. In the observed repro this was a weather request asking for hourly rain risk, wind, and temperature.
3. In topic B, send a second prompt at roughly the same time. In the observed repro this was a shorter weather summary request.
4. Compare the gateway timestamps for inbound message handling, session start, queue diagnostics, and Telegram reply send time.

Expected behavior

Messages sent to different Telegram forum topics in the same group should be allowed to enter the agent pipeline independently when they route to distinct topic/session keys. A prompt in topic B should not wait for topic A's reply to be sent before it is even logged as inbound.

Actual behavior

Topic B was sent by the user at approximately the same local minute as topic A, but the gateway did not log topic B as inbound until 359 ms after topic A's sendMessage ok log line. This makes different Telegram topics behave as if they are serialized before the agent pipeline, even though the topic session keys are distinct.

OpenClaw version

OpenClaw 2026.5.12 (0e30120)

Operating system

Ubuntu 24.04.3 LTS, Linux 6.17.0-1011-oracle, aarch64

Install method

npm global, systemd user gateway service

Model

openai/gpt-5.5 via OpenAI Codex runtime

Provider / routing chain

OpenClaw Telegram channel -> OpenClaw gateway -> OpenAI Codex OAuth model route

Additional provider/model setup details

Fallback configured: google/gemini-2.5-flash.

Queue mode shown by /status: steer.

Relevant local concurrency config:

{
  "agents": {
    "defaults": {
      "maxConcurrent": 4,
      "subagents": {
        "maxConcurrent": 4
      }
    }
  }
}

The Telegram bundled plugin manifest on this install has id telegram; no separate plugin version was shown in the bundled manifest, so Telegram plugin version is NOT_ENOUGH_INFO.

This repro used Telegram forum topics in the same group/chat. Real group id, topic ids, message ids, session ids, connection ids, request ids, user ids, and bot username are redacted below.

Logs, screenshots, and evidence

The user reported sending both test messages at approximately 23:54 local time (22:54 UTC) on 2026-05-14, one in the General topic and one in the Morning Brief topic.

Redacted gateway log timeline:

# Topic A / General
2026-05-14T22:54:11.114+00:00 [telegram] Inbound message telegram:group:<TELEGRAM_GROUP_ID>:topic:<TOPIC_A> -> @<BOT_USERNAME> (group, 93 chars)
2026-05-14T22:54:13.821+00:00 [plugins] active-memory: agent=main session=agent:main:telegram:group:<TELEGRAM_GROUP_ID>:topic:<TOPIC_A> activeProvider=openai activeModel=gpt-5.5 start timeoutMs=30000 queryChars=4011 searchQueryChars=93
2026-05-14T22:54:20.549+00:00 [diagnostic] liveness warning: reasons=event_loop_delay interval=30s eventLoopDelayP99Ms=50 eventLoopDelayMaxMs=1051.7 eventLoopUtilization=0.204 cpuCoreRatio=0.259 active=2 waiting=0 queued=1 phase=channels.telegram.start-account work=[active=agent:main:telegram:group:<TELEGRAM_GROUP_ID>:topic:<TOPIC_A>(processing,q=1,age=9s last=embedded_run:ended)|agent:main:telegram:group:<TELEGRAM_GROUP_ID>:topic:<TOPIC_A>:active-memory:<ACTIVE_MEMORY_RUN_ID>(processing/embedded_run,q=0,age=4s last=codex_app_server:notification:rawResponseItem/completed) queued=agent:main:telegram:group:<TELEGRAM_GROUP_ID>:topic:<TOPIC_A>(processing,q=1,age=9s last=embedded_run:ended)]
2026-05-14T22:54:30.190+00:00 [plugins] active-memory: agent=main session=agent:main:telegram:group:<TELEGRAM_GROUP_ID>:topic:<TOPIC_A> activeProvider=openai activeModel=gpt-5.5 done status=ok elapsedMs=16369 summaryChars=80
2026-05-14T22:55:32.328+00:00 [telegram] sendMessage ok chat=<TELEGRAM_GROUP_ID> message=<MESSAGE_ID_A>

# Topic B / Morning Brief
2026-05-14T22:55:32.687+00:00 [telegram] Inbound message telegram:group:<TELEGRAM_GROUP_ID>:topic:<TOPIC_B> -> @<BOT_USERNAME> (group, 66 chars)
2026-05-14T22:55:35.198+00:00 [plugins] active-memory: agent=main session=agent:main:telegram:group:<TELEGRAM_GROUP_ID>:topic:<TOPIC_B> activeProvider=openai activeModel=gpt-5.5 start timeoutMs=30000 queryChars=66 searchQueryChars=66
2026-05-14T22:55:45.767+00:00 [plugins] active-memory: agent=main session=agent:main:telegram:group:<TELEGRAM_GROUP_ID>:topic:<TOPIC_B> activeProvider=openai activeModel=gpt-5.5 done status=no_relevant_memory elapsedMs=10569 summaryChars=0
2026-05-14T22:56:18.331+00:00 [telegram] sendMessage ok chat=<TELEGRAM_GROUP_ID> message=<MESSAGE_ID_B>

Key timing evidence:

Topic A inbound: 2026-05-14T22:54:11.114Z
Topic A reply:   2026-05-14T22:55:32.328Z
Topic B inbound: 2026-05-14T22:55:32.687Z
Topic B reply:   2026-05-14T22:56:18.331Z

Topic B's inbound log appears 359 ms after topic A's reply was sent, even though the user sent both Telegram messages at approximately the same local minute.

Additional same-version evidence from earlier in the same gateway session shows topic-specific session keys are distinct, so this does not appear to be simple session-key collapse across topics:

2026-05-14T22:18:14.639+00:00 [telegram] Inbound message telegram:group:<TELEGRAM_GROUP_ID>:topic:<TOPIC_A> -> @<BOT_USERNAME> (group, 47 chars)
2026-05-14T22:18:17.402+00:00 [plugins] active-memory: agent=main session=agent:main:telegram:group:<TELEGRAM_GROUP_ID>:topic:<TOPIC_A> activeProvider=openai activeModel=gpt-5.5 start timeoutMs=30000 queryChars=19624 searchQueryChars=47

2026-05-14T22:27:34.640+00:00 [telegram] Inbound message telegram:group:<TELEGRAM_GROUP_ID>:topic:<TOPIC_B> -> @<BOT_USERNAME> (group, 192 chars)
2026-05-14T22:27:37.418+00:00 [plugins] active-memory: agent=main session=agent:main:telegram:group:<TELEGRAM_GROUP_ID>:topic:<TOPIC_B> activeProvider=openai activeModel=gpt-5.5 start timeoutMs=30000 queryChars=192 searchQueryChars=192

Earlier same-version long-running queue evidence in one Telegram forum topic:

2026-05-14T21:55:19.524+00:00 [diagnostic] long-running session: sessionId=<SESSION_ID> sessionKey=agent:main:telegram:group:<TELEGRAM_GROUP_ID>:topic:<TOPIC_A> state=processing age=143s queueDepth=1 reason=queued_behind_active_work classification=long_running activeWorkKind=embedded_run lastProgress=codex_app_server:notification:hook/started lastProgressAge=2s recovery=none

Related upstream issues / changes that may be relevant:

• #48003 reports active-run steering messages not reaching active runs because messages are serialized before steering can occur.
• #53023 requests configurable per-session lane concurrency / auto-yield because session lanes are effectively serialized.
• Commit 70df2b8 / PR #77023 changed default mid-turn prompt behavior to active-run steering and retired legacy queue modes.

Diagnostic requested by Discord bot / Molty: is session key or conversation routing now collapsing multiple Telegram topics into one serialized session queue?

Observed answer from the logs: topic session keys appear distinct (...:topic:<TOPIC_A>, ...:topic:<TOPIC_B>), so the visible evidence does not prove cross-topic session-key collapse. However, topic B did not reach the gateway inbound log until topic A's reply completed, suggesting serialization may be happening earlier in Telegram/group handling or in a per-chat sequential queue before topic-specific agent dispatch.

Impact and severity

Affected: Telegram users using forum topics for parallel command-center style workflows.

Severity: Medium to high. This blocks multi-topic use where separate topic requests are expected to proceed independently.

Frequency: Observed in the repro above; broader frequency is NOT_ENOUGH_INFO.

Consequence: A long-running request in one Telegram topic can make another topic appear stalled or single-threaded before it reaches the agent pipeline.

Additional information

This looks more like Telegram/group ingress serialization or active-run queue behavior than a local global concurrency configuration issue. Local config still allows global parallelism (agents.defaults.maxConcurrent: 4, agents.defaults.subagents.maxConcurrent: 4), and the logs show distinct topic session keys.

A possible area to inspect is whether the Telegram integration has a per-chat sequentializer that serializes all updates for a group before topic-specific routing/dispatch, similar to the Feishu per-chat queue behavior described in #54409 and the topic-lane fix pattern in #64920.