Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: sessions_send loses Telegram forum topic delivery and can pollute requester transcripts [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#43848•Fetched 2026-04-08 00:18:41
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
UntaDotMyUntaDotMy
Participants
UntaDotMyUntaDotMy
Timeline (top)
cross-referenced ×2

sessions_send between Telegram supergroup forum topics can lose topic delivery, skip the visible post, or echo topic-to-topic handoff text back into the requester transcript.

Root Cause

Expected behavior

  • The visible post is delivered into the target Telegram topic, not the hidden supergroup root.
  • Topic delivery preserves the target threadId.
  • If the target session already produced the intended visible reply, the visible handoff does not disappear just because the announce step returned ANNOUNCE_SKIP.
  • Topic-to-topic sessions_send traffic does not inject stale inter_session turns back into the requester transcript.

Fix Action

Fix / Workaround

Additional information

I have a focused patch and regression tests prepared for:

  • preserving Telegram threadId in announce target resolution and final send
  • reusing the target reply for visible Telegram topic handoffs when announce returns ANNOUNCE_SKIP
  • suppressing ping-pong for same-agent room moves and Telegram topic-to-topic handoffs

PR fix notes

PR #43869: fix: preserve Telegram forum topic delivery for sessions_send

Description (problem / solution / changelog)

Summary

  • Problem: sessions_send can lose Telegram forum topic delivery, suppress visible topic handoffs when announce returns ANNOUNCE_SKIP, and echo topic-to-topic handoff text back into the requester transcript.
  • Why it matters: Telegram supergroup forum users can miss visible replies, get messages in the wrong place, and carry polluted requester context into later turns.
  • What changed: preserve Telegram threadId during announce target resolution and final send, reuse the target reply for visible Telegram topic handoffs when announce skips, and suppress ping-pong for same-agent room moves plus Telegram topic-to-topic handoffs.
  • What did NOT change (scope boundary): no company-specific workflow logic, no bootstrap/session-seeding changes, and no channel behavior changes outside the sessions_send announce path.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #43848
  • Related #4911

User-visible / Behavior Changes

  • Telegram forum-topic announce delivery now preserves the target topic thread when sessions_send posts back visibly.
  • Visible Telegram topic handoffs no longer disappear just because the announce step returns ANNOUNCE_SKIP after the target already produced the intended reply.
  • Telegram topic-to-topic handoffs no longer run reply-back ping-pong into the requester transcript.

Security Impact (required)

  • New permissions/capabilities? (No)
  • Secrets/tokens handling changed? (No)
  • New/changed network calls? (No)
  • Command/tool execution surface changed? (No)
  • Data access scope changed? (No)
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS: Ubuntu 24.04.4 LTS
  • Runtime/container: npm global install, local source checkout for validation
  • Model/provider: openai-responses / gpt-5.4 for local repro; bug is transport-side and model-independent
  • Integration/channel (if any): Telegram supergroup forum topics
  • Relevant config (redacted): Telegram topic sessions bound under channels.telegram.groups.<chatId>.topics.<topicId>

Steps

  1. Bind persistent OpenClaw sessions to Telegram supergroup forum topics.
  2. Trigger sessions_send from one Telegram topic session to another with a prompt that should post visibly in the target topic.
  3. Observe the target reply/announce flow, including cases where the target already produced a real reply but the announce step returns ANNOUNCE_SKIP.

Expected

  • Visible delivery stays in the target Telegram topic.
  • The visible post survives the announce step when the target already produced the intended reply.
  • Topic-to-topic traffic does not echo new inter_session requester turns back into the source transcript.

Actual

  • Topic delivery can fall back to chat-level routing without the forum thread.
  • Visible handoffs can disappear when announce returns ANNOUNCE_SKIP.
  • Topic-to-topic ping-pong can contaminate the requester transcript.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios: targeted Vitest coverage for announce target hydration, same-agent Telegram topic room moves, and visible Telegram topic handoffs that hit ANNOUNCE_SKIP; full pnpm build; full pnpm check.
  • Edge cases checked: legacy non-agent session keys do not get treated as same-agent room moves; Telegram lookup still hydrates the final thread even when plugin metadata is not the deciding factor.
  • What you did not verify: live Telegram delivery from this upstream checkout against a real bot token.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes)
  • Config/env changes? (No)
  • Migration needed? (No)
  • If yes, exact upgrade steps:

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: revert this PR or install the prior package version.
  • Files/config to restore: src/agents/tools/sessions-announce-target.ts, src/agents/tools/sessions-send-helpers.ts, src/agents/tools/sessions-send-tool.a2a.ts
  • Known bad symptoms reviewers should watch for: non-Telegram sessions_send announce routing unexpectedly changing, or Telegram topic sends losing visible delivery.

Risks and Mitigations

  • Risk: suppressing ping-pong for Telegram topic-to-topic handoffs could change workflows that relied on hidden refinement loops.
    • Mitigation: the suppression is limited to topic-to-topic handoffs and covered by targeted regression tests for visible delivery plus existing non-Telegram ping-pong tests.

Changed files

  • src/agents/openclaw-tools.sessions.test.ts (modified, +344/-0)
  • src/agents/tools/sessions-announce-target.ts (modified, +9/-3)
  • src/agents/tools/sessions-helpers.ts (modified, +1/-0)
  • src/agents/tools/sessions-send-helpers.ts (modified, +85/-0)
  • src/agents/tools/sessions-send-tool.a2a.ts (modified, +20/-3)
  • src/agents/tools/sessions.test.ts (modified, +30/-0)

PR #44064: Fix Telegram sessions_send announce delivery

Description (problem / solution / changelog)

Summary

Fix sessions_send Telegram announce delivery regressions for direct/threaded targets.

This PR addresses a cluster of issues in the same delivery chain:

  • preserve Telegram threadId during announce-target resolution
  • pass threadId through to the final gateway send
  • stop forcing Telegram-originated sessions_send turns onto webchat
  • when the nested announce step returns ANNOUNCE_SKIP, fall back to the target session's actual reply for the visible external delivery

Why

In a real repro (Telegram group session -> sessions_send -> Telegram DM General topic), the delivery path could fail in multiple ways:

  1. target resolution kept channel/to/accountId but lost the DM topic threadId
  2. the initial injected nested turn was always stamped with INTERNAL_MESSAGE_CHANNEL (webchat), which caused routing confusion in Telegram-bound sessions
  3. the nested announce step often returned ANNOUNCE_SKIP, which suppressed the visible external send entirely even though the target session had already produced the real reply text

These failures could combine into "reply exists in history but nothing visible is delivered" behavior.

Changes

  • src/agents/tools/sessions-send-tool.ts
    • use opts?.agentChannel ?? INTERNAL_MESSAGE_CHANNEL for the injected nested turn
  • src/agents/tools/sessions-announce-target.ts
    • hydrate threadId alongside channel/to/accountId from session lookup / extracted delivery info
  • src/agents/tools/sessions-send-tool.a2a.ts
    • include threadId in final send
    • if announce reply is skipped, fall back to primaryReply / latestReply for visible external delivery
  • tests
    • cover Telegram direct-thread announce target resolution
    • cover ANNOUNCE_SKIP fallback sending the round-one reply to a Telegram threaded target
    • adjust sessions_send expectations so the initial message-context turn preserves the originating external channel

Repro covered

  • Telegram group session triggers sessions_send into a Telegram DM topic session
  • target session replies normally
  • announce step returns ANNOUNCE_SKIP
  • visible Telegram delivery now uses the target reply with preserved threadId

Tests

corepack pnpm -s vitest run src/agents/tools/sessions.test.ts src/agents/openclaw-tools.sessions.test.ts

Related issues

  • Closes #43848
  • Related: #43318
  • Related: #34308

Changed files

  • src/agents/openclaw-tools.sessions.test.ts (modified, +225/-2)
  • src/agents/tools/sessions-announce-target.ts (modified, +13/-4)
  • src/agents/tools/sessions-send-tool.a2a.ts (modified, +20/-2)
  • src/agents/tools/sessions.test.ts (modified, +27/-0)
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Summary

sessions_send between Telegram supergroup forum topics can lose topic delivery, skip the visible post, or echo topic-to-topic handoff text back into the requester transcript.

Steps to reproduce

  1. Configure OpenClaw 2026.3.11 with Telegram supergroup forum topics bound to persistent sessions.
  2. Trigger sessions_send from one Telegram topic session to another topic session in the same supergroup.
  3. Use a prompt that expects a visible post in the target topic, then let the target session complete its normal reply and announce flow.
  4. Repeat with topic-to-topic traffic where the target session produces a real reply but the announce step returns ANNOUNCE_SKIP.

Expected behavior

  • The visible post is delivered into the target Telegram topic, not the hidden supergroup root.
  • Topic delivery preserves the target threadId.
  • If the target session already produced the intended visible reply, the visible handoff does not disappear just because the announce step returned ANNOUNCE_SKIP.
  • Topic-to-topic sessions_send traffic does not inject stale inter_session turns back into the requester transcript.

Actual behavior

  • Announce delivery can resolve only the chat-level target and miss the topic/thread, so the visible post appears to vanish from the forum topic.
  • When the target session already produced the right visible reply, the final visible post can still be suppressed if the announce step returns ANNOUNCE_SKIP.
  • Topic-to-topic ping-pong can echo target replies back into the requester transcript as fresh inter_session user turns.

OpenClaw version

2026.3.11

Operating system

Ubuntu 24.04.4 LTS

Install method

npm global install

Model

openai-responses / gpt-5.4 (bug is transport-side and model-independent)

Provider / routing chain

openclaw -> OpenAI Responses API (bug is in sessions_send announce routing, not model selection)

Config file / key location

~/.openclaw/openclaw.json; Telegram forum topic sessions bound under channels.telegram.groups.<chatId>.topics.<topicId>

Additional provider/model setup details

The repro depends on Telegram forum-topic sessions and sessions_send announce delivery. It does not depend on a specific model provider.

Logs, screenshots, and evidence

  • The target topic session can produce a valid reply while the final visible post still does not appear in the Telegram topic.
  • A reliable code-level repro is that announce target resolution can return channel/to without preserving the topic threadId for Telegram forum sends.
  • In the same flow, topic-to-topic ping-pong can write fresh inter_session requester turns sourced from the target topic, which contaminates later requester-session context.

Impact and severity

Affected: Telegram supergroup forum users relying on topic-bound sessions and sessions_send Severity: High for forum workflows because visible handoffs can silently disappear and requester transcripts can be polluted Frequency: Reproducible in topic-to-topic handoffs Consequence: Missing visible replies, replies landing in the wrong place, and contaminated requester session history

Additional information

I have a focused patch and regression tests prepared for:

  • preserving Telegram threadId in announce target resolution and final send
  • reusing the target reply for visible Telegram topic handoffs when announce returns ANNOUNCE_SKIP
  • suppressing ping-pong for same-agent room moves and Telegram topic-to-topic handoffs

extent analysis

Fix Summary

Preserve Telegram threadId during sessions_send announce routing, reuse the target’s visible reply when ANNOUNCE_SKIP is returned, and block “ping‑pong” inter‑session turns for same‑agent/topic hand‑offs.

The changes live in the src/channels/telegram/announce.ts (or equivalent) and the src/sessions/send.ts** logic that builds the announce target.

Step‑by‑Step Fix Plan

1. Extend the announce target shape

// src/types.ts
export interface TelegramTarget {
  chatId: string;          // super‑group id
  threadId?: string;       // forum‑topic id (optional)
  // …existing fields
}

2. Preserve threadId when resolving the target

// src/channels/telegram/announce.ts
function resolveAnnounceTarget(
  src: Session, dst: Session
): TelegramTarget {
  const base = {
    chatId: dst.channel.chatId,
    // keep any existing threadId from the destination session
    threadId: dst.channel.threadId,
  };

  // old code overwrote threadId → remove that line
  // base.threadId = undefined;

  return base;
}

3. Pass the target unchanged to the final send

// src/sessions/send.ts
async function sessionsSend(src, dst, payload) {
  const announceTarget = resolveAnnounceTarget(src, dst);

  // send announce (may return ANNOUNCE_SKIP)
  const announceResult = await telegram.sendAnnounce(announceTarget, payload);

  // ---- NEW: reuse visible reply when ANNOUNCE_SKIP ----
  if (announceResult === 'ANNOUNCE_SKIP' && payload.visibleReply) {
    // send the already‑generated visible reply directly to the target topic
    await telegram.sendMessage({
      chatId: announceTarget.chatId,
      threadId: announceTarget.threadId,   // guaranteed to be present now
      text: payload.visibleReply,
    });
    // skip the normal announce flow
    return;
  }

  // normal flow continues …
}

4. Guard against ping‑pong inter‑session turns

// src/sessions/send.ts (after receiving a reply from the target)
if (src.agentId === dst.agentId && src.channel.chatId === dst.channel.chatId)

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

  • The visible post is delivered into the target Telegram topic, not the hidden supergroup root.
  • Topic delivery preserves the target threadId.
  • If the target session already produced the intended visible reply, the visible handoff does not disappear just because the announce step returned ANNOUNCE_SKIP.
  • Topic-to-topic sessions_send traffic does not inject stale inter_session turns back into the requester transcript.
#api#ssr#installation#tensor shape#autograd error#authentication issue#prompt issue#agent setup#task chaining

Still need to ship something?

×6

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

Back to top recommendations

TRENDING