Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Announce delivery constructs malformed recipient "group:<chatId>" for Telegram forum topic sessions [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#57918•Fetched 2026-04-08 01:56:07
View on GitHub
Comments
0
Participants
1
Timeline
7
Reactions
0
Author
dLcchdLcch
Participants
dLcchdLcch
Timeline (top)
cross-referenced ×3labeled ×2referenced ×2

When sessions_send completes an async (fire-and-forget) delegation between agents in a Telegram forum topic session, the announce delivery step constructs the recipient as "group:-10...2" instead of parsing the session key into numeric chat_id + message_thread_id, causing "Telegram recipient must be a numeric chat ID" error.

Error Message

When sessions_send completes an async (fire-and-forget) delegation between agents in a Telegram forum topic session, the announce delivery step constructs the recipient as "group:-10...2" instead of parsing the session key into numeric chat_id + message_thread_id, causing "Telegram recipient must be a numeric chat ID" error. 3. Explicit error with invalid recipient format "group:-10...2"

  • Severity: Blocks workflow. Async delegation results are silently dropped — the human user never receives the agent's response in the Telegram topic. The orchestrator agent believes delivery succeeded (no error surfaces to the LLM), so it does not retry.

Root Cause

  • Affected users/systems/channels: Any multi-agent setup using Telegram forum topics (supergroups with topics enabled) where agents communicate via async sessions_send (timeoutSeconds: 0). Specifically affects the announce delivery path — the mechanism that delivers inter-agent results back to the originating Telegram topic.
  • Severity: Blocks workflow. Async delegation results are silently dropped — the human user never receives the agent's response in the Telegram topic. The orchestrator agent believes delivery succeeded (no error surfaces to the LLM), so it does not retry.
  • Frequency: Always reproducible when all conditions are met (forum topic session + async sessions_send + announce delivery step). Three out of three async delegations failed on 2026-03-30. Synchronous sessions_send (timeoutSeconds > 0) is not affected because results return in-band, bypassing announce.
  • Consequence: Missed messages — delegation results computed by worker agents are lost from the user's perspective. Duplicate processing was also observed: the announce mechanism retried internally, causing the worker agent to process the same task twice (two S-OK returns for one delegation). Workaround requires switching all inter-agent delegations to synchronous mode, which blocks the orchestrator's Telegram session for up to 120s per delegation.

Fix Action

Fix / Workaround

Workaround: using sessions_send with timeoutSeconds: 120 (synchronous) to receive results in-band, bypassing announce entirely. Fallback: openclaw message send --channel telegram --target -10...2 --thread-id 42 via exec.

  • Affected users/systems/channels: Any multi-agent setup using Telegram forum topics (supergroups with topics enabled) where agents communicate via async sessions_send (timeoutSeconds: 0). Specifically affects the announce delivery path — the mechanism that delivers inter-agent results back to the originating Telegram topic.
  • Severity: Blocks workflow. Async delegation results are silently dropped — the human user never receives the agent's response in the Telegram topic. The orchestrator agent believes delivery succeeded (no error surfaces to the LLM), so it does not retry.
  • Frequency: Always reproducible when all conditions are met (forum topic session + async sessions_send + announce delivery step). Three out of three async delegations failed on 2026-03-30. Synchronous sessions_send (timeoutSeconds > 0) is not affected because results return in-band, bypassing announce.
  • Consequence: Missed messages — delegation results computed by worker agents are lost from the user's perspective. Duplicate processing was also observed: the announce mechanism retried internally, causing the worker agent to process the same task twice (two S-OK returns for one delegation). Workaround requires switching all inter-agent delegations to synchronous mode, which blocks the orchestrator's Telegram session for up to 120s per delegation.

PR fix notes

PR #58273: fix(telegram): add resolveSessionTarget to fix announce delivery for forum topics

Description (problem / solution / changelog)

Summary

  • Adds the missing resolveSessionTarget hook to the Telegram channel plugin, fixing announce delivery for forum topic sessions in multi-agent async delegations.
  • Without this hook, resolveAnnounceTargetFromKey falls back to the malformed "group:<chatId>" target string, which Telegram rejects with "must be a numeric chat ID".
  • Discord and Slack already implement this hook; this change brings Telegram to parity.

Fixes #57918

Root cause

resolveAnnounceTargetFromKey() in sessions-send-helpers.ts constructs a genericTarget = "group:<chatId>" from the session key. It then calls resolveSessionTarget (if available) or falls back to normalizeTarget. Telegram did not implement resolveSessionTarget, and its normalizeTarget (normalizeTelegramMessagingTarget) returns undefined for bare "group:<chatId>" input (because stripTelegramInternalPrefixes only strips the group: prefix when preceded by telegram:). The final fallback returns the raw "group:<chatId>" string, which fails at send time.

Changes

FileChange
extensions/telegram/src/channel.tsAdd resolveSessionTarget: ({ id }) => id to the messaging adapter
src/agents/tools/sessions-send-helpers.test.tsUpdate Telegram test stub to include resolveSessionTarget matching real behavior

Test plan

  • pnpm test -- sessions-send-helpers.test.ts — 3/3 passed
  • pnpm check — lint, typecheck, format all pass
  • Manual verification: configure two agents with Telegram forum topic, trigger async sessions_send (timeoutSeconds: 0), confirm announce delivery reaches the correct topic

Changed files

  • extensions/telegram/src/channel.ts (modified, +1/-0)
  • src/agents/tools/sessions-send-helpers.test.ts (modified, +1/-0)

PR #58282: fix(telegram): add resolveSessionTarget for forum topic announce delivery

Description (problem / solution / changelog)

Summary

  • Problem: Telegram forum topic sessions use keys like agent:main:telegram:group:-1003284013439:topic:42. When announce delivery resolves the target via resolveAnnounceTargetFromKey, it constructs group:-1003284013439 and passes it to normalizeTarget. The Telegram normalizer fails to parse the group: prefix without a telegram: namespace, returns undefined, and the malformed recipient is used verbatim.
  • Why it matters: All announce deliveries to Telegram forum topic sessions fail silently.
  • What changed: Added resolveSessionTarget to the Telegram channel plugin messaging adapter. Updated test stub.
  • What did NOT change: normalizeTarget remains as fallback.

Change Type

  • Bug fix

Scope

  • Channels (Telegram)

Linked Issue

Fixes #57918

User-visible / Behavior Changes

Announce deliveries to Telegram forum topic sessions now correctly resolve the chat ID.

Security Impact

  • Permissions or access control? No
  • Secrets, tokens, or credentials? No
  • Network requests or external connections? No
  • Command execution or tool invocation? No
  • Data access patterns or storage? No

Evidence

  • Test case sessions-send-helpers.test.ts line 97-102 validates to: "-100123" with threadId: "99"
  • All 4 tests pass
  • Matches Discord and Slack resolveSessionTarget pattern

Human Verification

  • Test stub mirrors production implementation
  • Discord/Slack use same pattern
  • normalizeTarget fallback still works
  • Not verified on live Telegram forum topic (no test environment)

Review Conversations

  • Replied to / resolved all bot review conversations

Compatibility / Migration

Backward compatible. No config changes.

Failure Recovery

Revert single commit. Watch for forum topic announce delivery failures.

Risks and Mitigations

None.

🤖 AI-assisted (Claude Code). Reviewed code, traced full delivery path, verified against Discord/Slack implementations.

Changed files

  • extensions/telegram/src/channel.ts (modified, +8/-0)
  • src/agents/tools/sessions-send-helpers.test.ts (modified, +6/-0)
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When sessions_send completes an async (fire-and-forget) delegation between agents in a Telegram forum topic session, the announce delivery step constructs the recipient as "group:-10...2" instead of parsing the session key into numeric chat_id + message_thread_id, causing "Telegram recipient must be a numeric chat ID" error.

Steps to reproduce

  1. Configure two agents (main + worker) with session.agentToAgent.maxPingPongTurns: 0
  2. Configure a Telegram supergroup as forum with topics declared in channels.telegram.groups.<id>.topics (e.g. topics: { "42": {} })
  3. In the Telegram forum topic, send a message that triggers the main agent
  4. Main agent delegates to worker via sessions_send with timeoutSeconds: 0 (fire-and-forget)
  5. Worker agent completes and returns S-OK
  6. Runtime attempts announce delivery to the originating Telegram topic session

Expected behavior

Announce delivery parses session key "agent:main:telegram:group:-10..2:topic:42" and delivers to chat_id: -10...2 with message_thread_id: 42 via Bot API sendMessage.

Actual behavior

Announce delivery constructs recipient as "group:-10...2" (extracting the "group:<id>" segment from the session key verbatim). Bot API rejects with "Telegram recipient must be a numeric chat ID". Logs show:

  • "announce delivery failed" with recipient "group:-10...2"
  • ANNOUNCE_SKIP on timeout scenarios
  • A phantom session key "agent:main:telegram:direct:group:-10...2" was also created by the runtime, mixing direct: and group: segments — suggesting the session key parser mishandles the group:<negativeId> portion.

Three incidents observed on 2026-03-30:

  1. ANNOUNCE_SKIP (timeout before delivery attempted)
  2. Silent delivery failure (announce ran, no message arrived)
  3. Explicit error with invalid recipient format "group:-10...2"

Workaround: using sessions_send with timeoutSeconds: 120 (synchronous) to receive results in-band, bypassing announce entirely. Fallback: openclaw message send --channel telegram --target -10...2 --thread-id 42 via exec.

OpenClaw version

2026.3.28

Operating system

macOS 26.3.1

Install method

Local (loopback, port 18789)

Model

openai/gpt-5.4

Provider / routing chain

openai/gpt-5.4 → anthropic/claude-sonnet-4-6 → openai-codex/gpt-5.4

Additional provider/model setup details

  • Two agents: main (gregorio, profile: full) and agent-ops (sandbox, coding tools)
  • session.agentToAgent.maxPingPongTurns: 0 (ADR-018, explicit S-OK protocol)
  • tools.sessions.visibility: all
  • tools.agentToAgent.allow: ["main", "agent-ops", "fiscal"]
  • channels.telegram.groups.-10...2.topics: { "XX": {}, "XX": {}, "XX": {} }
  • session.dmScope: per-channel-peer
  • session.reset.idleMinutes: 30
  • Telegram long polling mode (no webhook)

Logs, screenshots, and evidence

Impact and severity

  • Affected users/systems/channels: Any multi-agent setup using Telegram forum topics (supergroups with topics enabled) where agents communicate via async sessions_send (timeoutSeconds: 0). Specifically affects the announce delivery path — the mechanism that delivers inter-agent results back to the originating Telegram topic.
  • Severity: Blocks workflow. Async delegation results are silently dropped — the human user never receives the agent's response in the Telegram topic. The orchestrator agent believes delivery succeeded (no error surfaces to the LLM), so it does not retry.
  • Frequency: Always reproducible when all conditions are met (forum topic session + async sessions_send + announce delivery step). Three out of three async delegations failed on 2026-03-30. Synchronous sessions_send (timeoutSeconds > 0) is not affected because results return in-band, bypassing announce.
  • Consequence: Missed messages — delegation results computed by worker agents are lost from the user's perspective. Duplicate processing was also observed: the announce mechanism retried internally, causing the worker agent to process the same task twice (two S-OK returns for one delegation). Workaround requires switching all inter-agent delegations to synchronous mode, which blocks the orchestrator's Telegram session for up to 120s per delegation.

Additional information

A related symptom was observed: the runtime created a phantom session with key "agent:main:telegram:direct:group:-10...2", mixing the "direct:" and "group:" segments. This malformed key was found in sessions.json and had to be removed manually. It suggests the session key parser may be mishandling negative numeric group IDs (e.g. treating "-10...2" as a segment boundary or confusing the "group:" prefix extraction). The phantom session was not created by any agent workspace instruction — Gregório confirmed no workspace file generates that format. After removal, the phantom session did not reappear during synchronous testing, but may recur under async conditions. Cannot confirm regression — this is the first time forum topics were used in this gateway instance, so no known-good version exists for this specific code path.

extent analysis

Fix Plan

To resolve the issue, we need to modify the session key parser to correctly handle negative numeric group IDs in the "group:" segment.

  • Update the session key parser to extract the numeric chat ID and message thread ID from the session key.
  • Modify the announce delivery step to use the extracted chat ID and message thread ID to construct the recipient.

Example code snippet in JavaScript:

// Update session key parser
function parseSessionKey(sessionKey) {
  const parts = sessionKey.split(":");
  const chatId = parts[parts.indexOf("group") + 1];
  const threadId = parts[parts.indexOf("topic") + 1];
  return { chatId: parseInt(chatId), threadId: parseInt(threadId) };
}

// Modify announce delivery step
function announceDelivery(sessionKey) {
  const { chatId, threadId } = parseSessionKey(sessionKey);
  const recipient = { chatId, threadId };
  // Use the constructed recipient to deliver the message via Bot API
  deliverMessage(recipient);
}

Verification

To verify the fix, follow these steps:

  • Configure the agents and Telegram supergroup as described in the issue reproduction steps.
  • Send a message that triggers the main agent to delegate to the worker agent via async sessions_send.
  • Verify that the announce delivery step successfully delivers the message to the originating Telegram topic session.
  • Check the logs to ensure that the recipient is constructed correctly and the message is delivered without errors.

Extra Tips

  • Ensure that the session key parser is correctly handling negative numeric group IDs and extracting the chat ID and message thread ID.
  • Test the fix with different scenarios, including synchronous and asynchronous sessions_send, to ensure that the issue is fully resolved.
  • Consider adding additional logging or monitoring to detect and handle any potential issues with the session key parser or announce delivery step.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Announce delivery parses session key "agent:main:telegram:group:-10..2:topic:42" and delivers to chat_id: -10...2 with message_thread_id: 42 via Bot API sendMessage.

#api#agent setup#model compatibility#GPU setup#container setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Announce delivery constructs malformed recipient "group:<chatId>" for Telegram forum topic sessions [2 pull requests, 1 participants]