fix(telegram): preserve forum topic routing

[kesslerio]

Summary

• Keep Telegram thread-not-found fallback for General topic (message_thread_id=1), while failing closed for explicit non-General forum topic sends and direct/private topic sends.
• Preserve Telegram topic routing for automatic async/heartbeat follow-ups by reusing stored topic thread IDs for plugin-owned group routes.
• Seed explicit cron announce targets into isolated-session delivery context so completion and heartbeat notices stay on the configured topic instead of falling back to an agent default group.
• Keep the effective diff focused on Telegram topic routing, cron delivery context, outbound target reconstruction, and the temporary current-main memory-core test-contract shim needed for CI.

Change Type

• Bug fix
• Refactor required for the fix
• Feature
• Documentation
• Tests only

Scope

Telegram extension outbound delivery, shared heartbeat target resolution, isolated cron session delivery metadata, and one test-only memory-core mock compatibility update for the current subagent runtime contract.

Linked Issue / PR

• Telegram forum topic replies not delivered to topic — message_thread_id missing from sendMessage API call #78755 independently reported missing message_thread_id on outbound Telegram forum sends and was closed as duplicate/superseded by the same topic-routing work.
• Forum topic replies land in General: message_thread_id dropped in session auto-reply delivery #78724 covered the final session auto-reply message_thread_id pass-through now present on main; this PR keeps the broader fail-closed and async-route preservation behavior.
• Adjacent historical thread/topic work reviewed: cron: keep failure destination for threaded delivery #43808, fix(cron): announce delivery for Telegram forum topics #49704, fix(announce): preserve threadId in subagent announce for Telegram DM topics #52824, [Bug] message tool sends files to DM instead of staying in Telegram topic #52286, [Bug]: main/systemEvent cron heartbeat inherits global heartbeat.to and leaks topic reminder to DM #73900, fix: recover Telegram sends from stale thread ids #12293, fix(telegram): safe DM threadless retry for missing message_thread_id #30892.

Root Cause

The Telegram sender retried 400: message thread not found by removing message_thread_id too broadly. That is safe only for General-topic recovery, but unsafe for explicit non-General forum topics and direct/private topic sends because Telegram can then deliver into the wrong root context.

A separate async path could reconstruct heartbeat/completion delivery from incomplete session metadata. Topic-scoped Telegram sessions and explicit cron announce jobs could lose the thread id before later automatic notices were sent.

Regression Test Plan

• Explicit forum topic text/media/sticker/poll sends reject after the first thread-not-found error and do not retry threadless.
• Topic-qualified recipient strings such as telegram:group:<id>:topic:<thread> fail closed.
• Direct/private and resolved username DM sends with explicit thread ids reject after the first thread-not-found error and do not retry threadless.
• Draft stream preview/materialize sends fail closed for non-General forum topics and keep the existing stricter DM-preview behavior.
• Heartbeat target resolution preserves stored thread IDs for plugin-owned group routes when only deliveryContext or origin.chatType carries the topic context.
• Explicit Telegram cron announce targets persist session delivery context with the resolved chat id and topic thread id.

Real behavior proof

• Behavior or issue addressed: Telegram topic sends must not silently retry without message_thread_id after Telegram reports message thread not found; async heartbeat/completion delivery must preserve the intended topic route instead of falling back to a group/default route.

• Real environment tested: Disposable OpenClaw staging gateway on NixOS Linux, PR worktree /tmp/openclaw-pr76920-merge, head f515e5d36ac1166b955838c21489390dbfd9dbe2, using @kesslerClawBot in a real Telegram forum group (-1003908474243). The staging gateway was started from this PR head, and the proof script used the PR's built Telegram runtime, sendMessageTelegram from dist/extensions/telegram/runtime-api.js.

• Exact steps or command run after this patch: Started the disposable gateway with OPENCLAW_CONFIG_PATH=/home/art/.local/state/openclaw-staging/disposable/openclaw.json and OPENCLAW_STATE_DIR=/home/art/.local/state/openclaw-staging/disposable/state, then ran a redacted proof script from /tmp/openclaw-pr76920-merge that exercised: root chat-scoped send to -1003908474243, explicit General topic -1003908474243:topic:1, invalid explicit non-General topic -1003908474243:topic:999999, and valid explicit non-General topic -1003908474243:topic:16.

• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output): Copied live output from the staging gateway/proof run. Full PR comment: fix(telegram): preserve forum topic routing #76920 (comment)

  Key copied output:

  head=f515e5d36ac1166b955838c21489390dbfd9dbe2
  chat=-1003908474243
  generalTopic=1
  [telegram] outbound send ok accountId=default chatId=-1003908474243 messageId=14 operation=sendMessage deliveryKind=text chunkCount=1
  rootSend=ok messageId=14 chatId=-1003908474243
  [telegram] outbound send ok accountId=default chatId=-1003908474243 messageId=15 operation=sendMessage deliveryKind=text chunkCount=1
  generalTopicSend=ok messageId=15 chatId=-1003908474243 topic=1
  [telegram] message failed: Call to 'sendMessage' failed! (400: Bad Request: message thread not found)
  invalidTopicSend=failed_closed topic=999999
  invalidTopicCheck=no_threadless_retry_observed
  
  nonGeneralTopicProof=head=f515e5d36ac1166b955838c21489390dbfd9dbe2
  nonGeneralTopic=16
  [telegram] outbound send ok accountId=default chatId=-1003908474243 messageId=17 operation=sendMessage deliveryKind=text threadId=16 chunkCount=1
  nonGeneralTopicSend=ok messageId=17 chatId=-1003908474243 topic=16
  

• Observed result after fix: Root chat-scoped send succeeded without a topic/thread id; General topic delivery succeeded and remained chat-scoped; an invalid explicit non-General forum topic failed closed and did not retry threadless; a valid explicit non-General forum topic sent with threadId=16, proving delivery stayed in the requested forum topic.

• What was not tested: I did not run a full live cron or heartbeat follow-up through the gateway in this proof pass. Existing focused tests still cover cron session delivery context and heartbeat topic-route reconstruction.

• Proof limitations or environment constraints: The live proof covers the real Telegram transport and topic send path. Cron/heartbeat route reconstruction remains covered by focused regression tests rather than a scheduled end-to-end cron/heartbeat run.

• Before evidence (optional but encouraged): ClawSweeper's current-main/source review for this PR identifies the pre-patch failure mode: explicit Telegram topic sends could retry threadless after message thread not found, and async follow-up routing could lose topic context. The after-fix proof above shows the explicit send path no longer retries threadless for an invalid non-General topic.

Verification

Current head 75acdc52684b07c8355966394f5ad5347a713e0a was refreshed against latest origin/main, trimmed back to the intended nine-file effective diff, and pushed after the commands above passed locally.

Security Impact

Reduces cross-topic message leakage in Telegram forum groups and private/direct topic contexts by failing closed when an explicit thread is stale or invalid, and by preserving topic context for automatic follow-up notices.

Compatibility / Migration

No config migration. Non-General forum topic and direct/private topic sends now surface the Telegram error instead of silently retrying threadless. Explicit cron announce routes now persist the intended delivery context for later automatic notices.

Risks

If an operator intentionally relied on stale explicit topic sends falling back to a root chat, those sends now fail. That behavior was the leakage bug this PR is meant to prevent.

The cron/session change is intentionally limited to resolved explicit delivery targets; bare delivery.mode: none jobs still avoid implicit last-target resolution.

AI Assistance

AI-assisted refresh, simplification, validation, and PR-body update.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 31, 2026, 7:15 AM ET / 11:15 UTC.

ClawSweeper review

What this changes

The branch limits Telegram threadless retries, preserves topic IDs through draft and media sends, and carries explicit cron topic routes into later heartbeat and completion delivery.

Merge readiness

⛔ Blocked until stronger real behavior proof is added - 6 items remain

Keep this PR open: it addresses a real Telegram cross-topic delivery problem and current main does not contain its central routing changes, but the branch is conflicted and its intended direct/private fallback change reverses the earlier DM-recovery direction without clear owner approval. The supplied live Telegram proof is meaningful but predates the current head’s media-caption fallback and does not prove the async cron/heartbeat path on the mergeable branch.

Priority: P1
Reviewed head: 16fe70e4f40588c626aa0e65a1a2143a5509d4ee
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The patch has focused routing tests and useful older live proof, but the current conflicted head lacks proof for its newest behavior and an owner decision is still needed for compatibility.
Proof confidence	🦐 gold shrimp (3/6)	Needs stronger real behavior proof before merge: The PR contains credible redacted live Telegram forum output, but it runs an older head and does not demonstrate the current media-caption fallback or current-head async route behavior; add redacted current-head evidence before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Patch quality	🦐 gold shrimp (3/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Needs proof	Needs stronger real behavior proof before merge: The PR contains credible redacted live Telegram forum output, but it runs an older head and does not demonstrate the current media-caption fallback or current-head async route behavior; add redacted current-head evidence before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed	6 items	Current-main gap: The current-main Telegram sender imports only the existing typing-thread helper and does not contain this PR's shared threadless-fallback policy or its explicit thread-not-found guard, so the central behavior is not already implemented on main. Changed routing boundary: The PR adds a shared policy that permits a threadless retry only for no thread or Telegram's General topic, with a separately gated DM path; the same policy is applied to normal sends and draft-stream sends. Prior compatible behavior: Merged PR #30892 established one-shot threadless recovery for DM-thread sends while keeping forum sends fail-closed. This branch intentionally changes the direct/private half of that established behavior, so the compatibility policy needs an owner decision.
Findings	1 actionable finding	[P1] Preserve DM recovery unless owners adopt the breaking contract
Security	None	None.

How this fits together

Telegram inbound topic metadata becomes an outbound message_thread_id when OpenClaw replies or sends media. Cron and heartbeat flows later reconstruct that delivery target from session state, so losing the topic ID can send automatic notices to the wrong chat context.

flowchart LR
  A[Telegram forum topic] --> B[Inbound session route]
  B --> C[Telegram outbound send]
  C --> D{Thread-not-found error?}
  D --> E[General-topic recovery]
  D --> F[Fail closed for explicit topic]
  G[Cron announce target] --> H[Session delivery context]
  H --> I[Heartbeat or completion route]
  I --> C

Loading

Decision needed

Question	Recommendation
Should explicit direct/private Telegram topic sends replace the previously merged DM threadless-retry recovery with fail-closed behavior when Telegram reports a stale thread?	Adopt fail-closed direct/private routing: Treat an explicit direct/private topic as a scoped destination, document the resulting delivery error, and require refreshed current-head proof before merge.

Why: This is a deliberate delivery-scope tradeoff: fail-closed behavior avoids cross-topic/root-chat leakage, while the prior merged behavior preserves recovery for stale DM thread IDs. Tests cannot choose the supported compatibility contract.

Before merge

• Add real behavior proof - Needs stronger real behavior proof before merge: The PR contains credible redacted live Telegram forum output, but it runs an older head and does not demonstrate the current media-caption fallback or current-head async route behavior; add redacted current-head evidence before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• Preserve DM recovery unless owners adopt the breaking contract (P1) - The branch makes direct/private stale-thread sends fail closed, while merged fix(telegram): safe DM threadless retry for missing message_thread_id #30892 established a one-shot DM threadless recovery path. This can break existing recoverable DM-thread sends; retain that behavior or obtain an explicit owner decision and document the upgrade contract before merging.
• Resolve merge risk (P1) - Merging would replace the previously merged DM stale-thread recovery behavior with fail-closed direct/private delivery for some existing routes; that may prevent cross-topic leakage but can also turn a formerly recoverable send into a user-visible failure.
• Resolve merge risk (P1) - The branch is currently conflicted with main, so the reviewed code is not yet the actual three-way merge result.
• Resolve merge risk (P2) - The live forum proof is from an older head and does not cover the current media-caption fallback or a current-head cron/heartbeat delivery run.

Findings

• [P1] Preserve DM recovery unless owners adopt the breaking contract — extensions/telegram/src/bot/helpers.ts:112-120

Agent review details

Security

None.

PR surface

Source +274, Tests +412. Total +686 across 12 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	6	356	82	+274
Tests	6	428	16	+412
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	12	784	98	+686

Review metrics

None.

Stored data model

Persistent data-model change detected: serialized state: src/cron/isolated-agent.direct-delivery-core-channels.test.ts. Confirm migration or upgrade compatibility proof before merge.

Mantis proof suggestion

A current-head Telegram Desktop recording would directly validate that valid topic media stays in the requested topic and invalid explicit topics do not fall back to the root chat. A maintainer can ask Mantis to capture proof by posting this exact PR comment:

@openclaw-mantis telegram desktop proof: verify the current PR head keeps valid forum text and media sends in the requested topic, while invalid explicit topics fail without root-chat fallback.

Merge-risk options

Maintainer options:

1. Resolve the fallback contract, then refresh (recommended)
   Choose the supported direct/private stale-thread behavior, rebase the branch cleanly, and prove the selected behavior on the current head before merging.
2. Accept the fail-closed behavior
   Merge only if an owner explicitly accepts that some stale direct/private sends will now surface an error instead of retrying to the root chat.
3. Pause the stale branch
   Do not merge the conflicted implementation if no owner wants to adopt the behavior change and refresh its proof.

Technical review

Best possible solution:

First make the direct/private fallback policy explicit: either preserve the established DM recovery path or accept fail-closed routing as the supported contract. Then rebase to a clean current-main result and provide redacted current-head proof for topic media plus one end-to-end async route before merge.

Do we have a high-confidence way to reproduce the issue?

No high-confidence current-main live reproduction was established in this review. The supplied base-fails/head-passes test and older live Telegram transcript make the transport bug source-reproducible, but the current conflicted head still needs a refreshed real setup run.

Is this the best way to solve the issue?

Unclear. The forum fail-closed path is the narrowest way to prevent root-chat misdelivery, but changing direct/private fallback behavior from the merged recovery policy needs an explicit owner decision before it can be called the best solution.

Full review comments:

• [P1] Preserve DM recovery unless owners adopt the breaking contract — extensions/telegram/src/bot/helpers.ts:112-120
  The branch makes direct/private stale-thread sends fail closed, while merged fix(telegram): safe DM threadless retry for missing message_thread_id #30892 established a one-shot DM threadless recovery path. This can break existing recoverable DM-thread sends; retain that behavior or obtain an explicit owner decision and document the upgrade contract before merging.
  Confidence: 0.82

Overall correctness: patch is incorrect
Overall confidence: 0.77

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 22911713e511.

Labels

Label justifications:

• P1: This PR addresses a real channel-routing regression that can misdeliver user-visible Telegram messages across topic or chat context.
• merge-risk: 🚨 compatibility: The branch changes the established direct-message stale-thread recovery behavior and can make existing recoverable sends fail.
• merge-risk: 🚨 message-delivery: The modified retry and media paths decide whether a Telegram message remains in its requested topic, retries elsewhere, or fails.
• merge-risk: 🚨 session-state: Cron session metadata and heartbeat route reconstruction now persist and reuse thread IDs for later automatic delivery.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR contains credible redacted live Telegram forum output, but it runs an older head and does not demonstrate the current media-caption fallback or current-head async route behavior; add redacted current-head evidence before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• mantis: telegram-visible-proof: Mantis should capture Telegram visible proof. Valid and invalid forum-topic text or media sends are user-visible Telegram behavior that can be demonstrated in a short Desktop recording on the current head.

Evidence

What I checked:

• Current-main gap: The current-main Telegram sender imports only the existing typing-thread helper and does not contain this PR's shared threadless-fallback policy or its explicit thread-not-found guard, so the central behavior is not already implemented on main. (extensions/telegram/src/send.ts:22, 22911713e511)
• Changed routing boundary: The PR adds a shared policy that permits a threadless retry only for no thread or Telegram's General topic, with a separately gated DM path; the same policy is applied to normal sends and draft-stream sends. (extensions/telegram/src/bot/helpers.ts:112, 16fe70e4f405)
• Prior compatible behavior: Merged PR fix(telegram): safe DM threadless retry for missing message_thread_id #30892 established one-shot threadless recovery for DM-thread sends while keeping forum sends fail-closed. This branch intentionally changes the direct/private half of that established behavior, so the compatibility policy needs an owner decision. (extensions/telegram/src/send.ts:569, e6e3a7b497f1)
• Async-route implementation: The branch persists a resolved explicit cron route into the isolated session and expands heartbeat reconstruction to reuse a group-route thread ID, with focused regression coverage for both paths. (src/cron/isolated-agent/run.ts:327, 16fe70e4f405)
• Proof is from an older head: The live Telegram forum transcript in fix(telegram): preserve forum topic routing #76920 (comment) exercises head f515e5d, while the current PR head is 16fe70e and adds the media-caption fallback fix. (extensions/telegram/src/send.test.ts:1969, 16fe70e4f405)
• Current merge state: GitHub reports the current branch as dirty against main, so correctness and proof still need to be refreshed on a mergeable current-main result. (16fe70e4f405)

Likely related people:

• steipete: The available feature history identifies Peter Steinberger as the recent author of the current Telegram fallback implementation that this PR refines and partially reverses. (role: recent area contributor; confidence: medium; files: extensions/telegram/src/send.ts, extensions/telegram/src/bot/helpers.ts)
• obviyus: Authored the merged DM-versus-forum fallback boundary in fix(telegram): safe DM threadless retry for missing message_thread_id #30892, which is the most direct compatibility predecessor for this branch. (role: earlier fallback-policy contributor; confidence: high; commits: e6e3a7b497f1; files: extensions/telegram/src/send.ts)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Rebase to a clean current-main result before asking for final review.
• Add redacted current-head Telegram proof for media-caption fallback and a cron or heartbeat follow-up route.
• Get explicit owner direction on direct/private stale-thread fallback behavior.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (1 earlier review cycle)

• reviewed 2026-07-03T21:02:47.376Z sha 16fe70e :: needs real behavior proof before merge. :: none

[kesslerio]

Follow-up pushed in d40225f83e.

Addressed the prior review items:

• Added cfg: TELEGRAM_TEST_CFG to the new Telegram send/sticker/poll tests and removed stale previewTransport test options that no longer exist in the draft stream API.
• Added a CHANGELOG.md entry.
• Extended the fix beyond thread-not-found retry: explicit cron announce topic routes are now persisted into isolated-session delivery context, and heartbeat target reconstruction preserves stored topic thread IDs for plugin-owned group routes when the session only has deliveryContext or origin.chatType.

Verification run locally:

• pnpm test src/infra/outbound/targets.test.ts src/cron/isolated-agent.direct-delivery-core-channels.test.ts extensions/telegram/src/send.test.ts extensions/telegram/src/draft-stream.test.ts
• pnpm test src/infra/heartbeat-runner.ghost-reminder.test.ts src/cron/isolated-agent/session.test.ts src/cron/isolated-agent.delivery-awareness.test.ts src/cron/isolated-agent/delivery-target.test.ts
• pnpm test extensions/telegram/src/send.test.ts extensions/telegram/src/draft-stream.test.ts
• pnpm exec oxfmt --check --threads=1 CHANGELOG.md extensions/telegram/src/send.test.ts extensions/telegram/src/draft-stream.test.ts src/cron/isolated-agent.direct-delivery-core-channels.test.ts src/cron/isolated-agent.test-setup.ts src/cron/isolated-agent/run.ts src/infra/outbound/targets.test.ts src/infra/outbound/targets.ts
• git diff --check
• pnpm check:changed

[kesslerio]

Rebased and refreshed this PR on current main.

Current head: 54b7b0d1f842
Base tested: origin/main 3f590b48280e
OpenClaw package version tested: 2026.5.12-beta.1
Node/pnpm: v22.21.1 / 11.1.0

Updates in this refresh:

• Resolved the rebase conflicts against current main.
• Kept the original fail-closed behavior for explicit non-General Telegram forum topics.
• Preserved the cron/heartbeat topic-route work from d40225f83e.
• Ran a simplification pass and collapsed the threadless fallback policy into the shared Telegram helper, while keeping normal send and draft-preview DM behavior distinct.
• Updated the PR body with tested versions, base/head SHAs, and the remaining live-proof residual.

Local verification:

• pnpm test extensions/telegram/src/send.test.ts extensions/telegram/src/draft-stream.test.ts
• pnpm test src/infra/outbound/targets.test.ts src/cron/isolated-agent.direct-delivery-core-channels.test.ts
• pnpm test src/infra/heartbeat-runner.ghost-reminder.test.ts src/cron/isolated-agent/session.test.ts src/cron/isolated-agent.delivery-awareness.test.ts src/cron/isolated-agent/delivery-target.test.ts
• pnpm check:changed
• git diff --check
• codex review --base origin/main

GitHub check status after push: mergeable, 88 checks passing, 20 skipped, 0 pending. The only failed check is still Real behavior proof, which is expected from the existing label/gate because I cannot provide after-fix live Telegram forum proof from this checkout. This needs maintainer override or a live Telegram bot/forum verification run.

[kesslerio]

Test-based reproduction proof

This is automated reproduction evidence for the threadless-fallback boundary in this PR. It is not a live Telegram forum smoke, so it should not be treated as replacing the remaining Real behavior proof gate unless maintainers accept test proof for that gate.

Base reproduces the bug boundary

Base: origin/main at 3f590b48280e

I added a temporary failing regression test to a clean base worktree:

pnpm test extensions/telegram/src/draft-stream.test.ts -- -t "reproduction: does not retry forum message preview sends without thread when thread is not found"

Result: failed as expected. Base retries a forum/topic preview send without message_thread_id after Telegram returns 400: Bad Request: message thread not found.

Key failure:

AssertionError: expected "vi.fn()" to be called 1 times, but got 2 times
extensions/telegram/src/draft-stream.test.ts:199:29

That proves the pre-fix behavior still has a threadless retry path for explicit forum sends.

PR head passes the fixed behavior

Head: 54b7b0d1f842

The same behavior is covered by the committed PR test:

pnpm test extensions/telegram/src/draft-stream.test.ts -- -t "does not retry forum message preview sends without thread when thread is not found"

Result:

Test Files  1 passed (1)
Tests  1 passed | 32 skipped (33)
[test] passed 1 Vitest shard

So the current PR head proves base-fails/head-passes for the explicit forum send retry case: when a forum/topic send has a message_thread_id, this PR now fails closed instead of retrying into the group root.

Residual: I still have not run a live Telegram forum bot smoke against this PR head. The local tests prove the fallback bug boundary; they do not prove end-to-end production Telegram delivery into a real forum topic.

[kesslerio]

@clawsweeper re-review

Rebased this branch onto current upstream/main and addressed the P2 finding plus current-main CI guardrail failures:

• Direct/private Telegram topic sends now fail closed on message thread not found; no threadless retry for DM/direct sends.
• PR body has the required Real Behavior Proof fields and current tested versions/head SHA.
• Patched the inherited lint/type/contract/OpenGrep failures that showed up after rebase (src/media/fetch.ts, plugin runtime config scope, Matrix test runtime boundary, and the sessions-patch lint cleanup).

Local checks run after the update:

pnpm check:test-types
pnpm lint --threads=8
pnpm test extensions/telegram/src/send.test.ts extensions/telegram/src/draft-stream.test.ts src/infra/outbound/targets.test.ts src/cron/isolated-agent.direct-delivery-core-channels.test.ts src/infra/heartbeat-runner.ghost-reminder.test.ts src/cron/isolated-agent/session.test.ts src/cron/isolated-agent.delivery-awareness.test.ts src/cron/isolated-agent/delivery-target.test.ts
pnpm test src/plugins/contracts/deprecated-internal-config-api.test.ts src/plugins/contracts/plugin-sdk-package-contract-guardrails.test.ts
pnpm test src/plugins/registry.runtime-config.test.ts src/media/fetch.test.ts extensions/matrix/src/matrix/subagent-hooks.test.ts

I could not run local OpenGrep because opengrep is not installed in this environment, but the reported direct Response.arrayBuffer() finding in src/media/fetch.ts is removed.

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/25816943869
• Updated: 2026-05-13T18:06:47.771Z

[RomneyDa]

Heads up: this PR needs to be updated against current main before the new required Dependency Guard check can pass.

[kesslerio]

@clawsweeper re_review

[kesslerio]

@clawsweeper re_review

[kesslerio]

@openclaw-mantis telegram desktop proof: verify current PR head keeps valid Telegram forum text/media sends in the requested topic and invalid explicit topics fail without a root-chat fallback.

[clawsweeper]

@kesslerio thanks for the PR. ClawSweeper is still waiting on real behavior proof before this can move forward.

Useful proof can be a screenshot, short video, terminal output, copied live output, linked artifact, or redacted logs that show the changed behavior after the fix. Please redact private tokens, phone numbers, private endpoints, customer data, and anything else sensitive.

Once proof is added to the PR body or a comment, ClawSweeper or a maintainer can re-check it.

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this pull request: fix(telegram): preserve forum topic routing This is item 1/1 in the current shard. Shard 40/44.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.

[obviyus]

Thanks for the careful work here. We retested current main at f2af4e9 with a real Telegram user in non-General forum topic 17. The inbound turn, typing state, and outbound reply all remained in topic 17, with one provider request and one reply. Since current main already has the intended behavior and we cannot reproduce the routing bug, this PR is no longer needed. Closing for now.