Summary

• Problem: Telegram DM/private-topic sends can fail with 400: Bad Request: message thread not found, but OpenClaw used to retry without the thread id and report success after sending into the plain DM instead of the intended topic.
• Why it matters: Users see a successful CLI/API result even though the message was not delivered to the requested Telegram topic, which hides Telegram routing failures and can put responses in the wrong conversation surface.
• What changed: Telegram DM-topic outbound sends now preserve the requested thread requirement and surface Telegram's message thread not found error instead of silently retrying threadless. Quote/formatting fallback behavior remains separate.
• What did NOT change (scope boundary): This PR does not claim to make Telegram deliver to the affected DM topic while Telegram rejects the topic id. It prevents false success and wrong-surface delivery. No gateway/task-registry changes and no UI/config behavior changes.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• 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 Telegram DM topics now require direct_messages_topic_id; message_thread_id falls back to main DM #79455
• Related issue comment: Telegram DM topics now require direct_messages_topic_id; message_thread_id falls back to main DM #79455 (comment)
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: Telegram DM-topic sends should not be reported as successful when Telegram rejects the requested topic id. The fix changes the real runtime behavior from “fallback to plain DM and return success” to “surface the Telegram failure.”
• Real environment tested: Ubuntu workstation, Node 22.22.0 via nvm, pnpm 10.33.2, OpenClaw gateway running from PR head dbec502085 (fix/78463-stale-running-tasks), Telegram bot @tmimmanuel_openclaw_bot, target chat 7116088418, topic id 42159.
• Exact steps or command run after this patch:
  1. Checked out PR head dbec502085 in /home/ubuntu/codes/tmimmanuel/openclaw-pr-78575.
  2. Ran pnpm install --frozen-lockfile.
  3. Started the gateway from the PR checkout with pnpm start gateway run --verbose.
  4. Sent a live Telegram DM-topic message through the gateway:

pnpm start message send \
  --channel telegram \
  --target 7116088418 \
  --thread-id 42159 \
  --message '[openclaw #79455 PR78575 retest 2026-05-09T03:30Z] no threadless fallback expected' \
  --json --verbose

• Evidence after fix (copied live terminal output and runtime log):

$ pnpm start message send --channel telegram --target 7116088418 --thread-id 42159 --message '[openclaw #79455 PR78575 retest 2026-05-09T03:30Z] no threadless fallback expected' --json --verbose

GatewayClientRequestError: GrammyError: Call to 'sendMessage' failed! (400: Bad Request: message thread not found)
ELIFECYCLE Command failed with exit code 1.
exit_status=1

2026-05-09T03:30:29.755+00:00 [telegram] message failed: Call to 'sendMessage' failed! (400: Bad Request: message thread not found)
2026-05-09T03:30:29.759+00:00 [ws] ⇄ res ✗ message.action 294ms errorCode=UNAVAILABLE errorMessage=GrammyError: Call to 'sendMessage' failed! (400: Bad Request: message thread not found) channel=telegram

• Observed result after fix: The gateway no longer returns a successful message.action after dropping the topic id. The CLI exits non-zero and exposes Telegram's message thread not found error, so OpenClaw does not silently send into the plain DM.
• What was not tested: Successful delivery into the exact Telegram DM topic, because Telegram still rejected message_thread_id for this bot/topic during the live test. A separate Telegram server/API fix or a reliable direct-topic parameter would be needed for successful topic delivery.
• Before evidence (optional but encouraged): On synced main 50898c4a72, the same target/topic returned success after fallback while logging the same Telegram rejection:

$ pnpm start message send --channel telegram --target 7116088418 --thread-id 42159 --message '[openclaw #79455 main retest 2026-05-09T01:56Z] synced main message_thread_id behavior' --json --verbose
{
  "action": "send",
  "channel": "telegram",
  "dryRun": false,
  "handledBy": "plugin",
  "payload": {
    "ok": true,
    "messageId": "15",
    "chatId": "7116088418"
  }
}

2026-05-09T01:56:14.179+00:00 [telegram] message failed: Call to 'sendMessage' failed! (400: Bad Request: message thread not found)
2026-05-09T01:56:14.389+00:00 [ws] ⇄ res ✓ message.action 383ms channel=telegram

Root Cause (if applicable)

• Root cause: The Telegram send path treated a DM/private-topic message_thread_id failure as recoverable and retried without thread parameters, which converted a topic send into a plain DM send while still returning success.
• Missing detection / guardrail: Tests covered the old threadless fallback behavior, so the wrong-surface success path was considered expected.
• Contributing context (if known): Telegram Bot API behavior around DM topics changed around Bot API 10.0; current live behavior still rejects message_thread_id for this bot/topic, and direct_messages_topic_id has been reported to return HTTP 200 without reliable topic placement.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/telegram/src/bot/delivery.test.ts, extensions/telegram/src/send.test.ts, extensions/telegram/src/draft-stream.test.ts.
• Scenario the test should lock in: DM-topic sends that Telegram rejects must not retry without the requested topic id and must not return success for wrong-surface delivery.
• Why this is the smallest reliable guardrail: The bug is in Telegram outbound fallback behavior, so focused Telegram send/delivery tests cover the behavior without changing gateway or channel contracts.
• Existing test that already covers this (if any): Existing Telegram delivery/send tests covered the old fallback path and were updated to lock the corrected behavior.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

Telegram DM-topic send failures are now visible to users instead of being masked by a plain-DM fallback. A send to an affected topic may fail with Telegram's message thread not found error until Telegram accepts a valid topic parameter for that chat.

Diagram (if applicable)

Before:
Telegram topic send -> Telegram rejects thread id -> OpenClaw retries without thread -> plain DM delivered -> success returned

After:
Telegram topic send -> Telegram rejects thread id -> OpenClaw returns failure -> no silent wrong-surface delivery

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: N/A

Repro + Verification

Environment

• OS: Ubuntu workstation
• Runtime/container: Node 22.22.0 via nvm, pnpm 10.33.2
• Model/provider: N/A
• Integration/channel (if any): Telegram, bot @tmimmanuel_openclaw_bot
• Relevant config (redacted): Target chat 7116088418, topic id 42159

Steps

1. Start gateway from synced main and send to Telegram target 7116088418 with --thread-id 42159.
2. Observe main logs Telegram's message thread not found but still returns success after fallback.
3. Start gateway from PR head dbec502085 and send the same command.
4. Observe PR branch returns a message.action failure and CLI exit code 1 instead of silently retrying without topic.
5. Run the focused Telegram checks listed below.

Expected

• Main reproduces the masked failure: Telegram rejects the topic send, OpenClaw still returns success after threadless fallback.
• PR branch does not mask the failure: Telegram rejects the topic send, OpenClaw returns an error and does not claim delivery success.

Actual

• Main 50898c4a72: returned success with messageId: 15 while logging 400: Bad Request: message thread not found.
• PR dbec502085: returned GatewayClientRequestError and exit code 1 with the same Telegram rejection.

Evidence

Attach at least one:

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

Supplemental checks:

• pnpm exec oxfmt --check --threads=1 CHANGELOG.md extensions/telegram/src/bot/delivery.send.ts extensions/telegram/src/bot/delivery.test.ts extensions/telegram/src/draft-stream.ts extensions/telegram/src/draft-stream.test.ts extensions/telegram/src/send.ts extensions/telegram/src/send.test.ts
• pnpm test extensions/telegram/src/bot/delivery.test.ts extensions/telegram/src/draft-stream.test.ts extensions/telegram/src/send.test.ts -- --reporter=verbose
• pnpm tsgo:extensions
• pnpm check:changed

Human Verification (required)

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

• Verified scenarios: Live Telegram DM-topic send on synced main still logs Telegram message thread not found and returns success after fallback; live Telegram DM-topic send on PR head returns failure instead of masked success; gateway logs show message.action changes from success on main to failure on PR.
• Edge cases checked: The tested path is a real Telegram bot/account/topic, not a mocked send. The PR keeps quote/formatting retry behavior separate from DM-topic threadless fallback.
• What you did not verify: Successful Telegram delivery into the affected DM topic, because the Telegram API rejected the topic id during the live PR-head test; unrelated Telegram media/sticker send paths in live mode.

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.

Compatibility / Migration

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

Risks and Mitigations

• Risk: Users affected by Telegram's DM-topic rejection will now see a send failure instead of receiving a message in the plain DM.
  • Mitigation: This is intentional: wrong-surface delivery is worse than a visible failure. The error now makes the Telegram API behavior explicit so users and maintainers can distinguish OpenClaw fallback behavior from Telegram topic-routing behavior.