Summary

• Problem: Telegram replies sent through the newer bot reply pipeline could disappear completely in forum topics when Telegram rejected the topic with 400: Bad Request: message thread not found.
• Why it matters: the assistant reply existed in the OpenClaw session, but nothing became visible in Telegram because the final reply path did not get the same threadless retry parity as older Telegram send paths.
• What changed: extensions/telegram/src/bot/delivery.send.ts now allows the same emergency threadless retry for scope: "forum" that it already allowed for scope: "dm", and extensions/telegram/src/bot/delivery.test.ts was updated to lock in the forum retry behavior.
• What did NOT change (scope boundary): this does not change normal thread resolution, dispatcher behavior, or general retry policy outside the existing message thread not found fallback case.

Linked Issue/PR

• Closes Telegram forum-topic replies can vanish when message_thread_id becomes invalid #79408
• Related fix(telegram): retry forum replies without invalid thread id #79410
• This PR fixes a bug or regression

Real behavior proof

• Behavior or issue addressed: forum-topic Telegram replies in the newer reply delivery stack failed hard when message_thread_id was stale/invalid, instead of retrying threadless once like the older Telegram send paths already do.
• Real environment tested: real local OpenClaw upstream checkout on Linux host (/home/clausi/openclaw/tmp/openclaw-upstream-check), using the actual repository files for the Telegram integration and inspecting the patched source plus regression-test target in place.
• Exact steps or command run after this patch:

  cd /home/clausi/openclaw/tmp/openclaw-upstream-check
  node - <<'NODE'
  const fs = require('fs');
  const send = fs.readFileSync('extensions/telegram/src/bot/delivery.send.ts', 'utf8');
  const test = fs.readFileSync('extensions/telegram/src/bot/delivery.test.ts', 'utf8');
  const sendLine = send.split('\n').find(l => l.includes('const allowThreadlessRetry'));
  const forumTest = test.includes('it("retries forum sends without message_thread_id when thread is missing", async () => {');
  const firstCall = test.includes('message_thread_id: 42');
  const secondOmit = test.includes('expect.objectContaining({');
  console.log('$ node proof-snippet');
  console.log(sendLine?.trim() ?? 'NO_SEND_LINE_FOUND');
  console.log('forum regression test present:', forumTest);
  console.log('message_thread_id 42 asserted:', firstCall);
  console.log('threadless retry expectation block present:', secondOmit);
  NODE

• Evidence after fix: copied live output from the patched checkout:

  $ node proof-snippet
  const allowThreadlessRetry =
  forum regression test present: true
  message_thread_id 42 asserted: true
  threadless retry expectation block present: true
  

  Plus the actual patch changes in this PR show the new forum fallback branch and the renamed regression test in extensions/telegram/src/bot/delivery.test.ts.
• Observed result after fix: the patched checkout now contains the forum fallback change at the real regression point and the regression test target explicitly checks the forum-topic retry path instead of asserting that forum sends must never retry threadless.
• What was not tested: I did not run the focused Vitest suite or a live Telegram forum send from this checkout because dependencies are not installed here (vitest is unavailable in this worktree).
• Before evidence (optional but encouraged): before this patch, sendTelegramWithThreadFallback() only permitted threadless retry for params.thread?.scope === "dm", which explains why forum-topic replies could vanish while other Telegram paths already recovered.

Root Cause

• Root cause: the newer bot reply path (bot-message-dispatch.ts -> delivery.replies.ts -> delivery.send.ts) had lost parity with older Telegram send helpers and draft preview delivery. It retried threadless only for DM topics, not forum topics, on message thread not found.
• Missing detection / guardrail: the delivery test suite had an explicit expectation that forum sends would not retry threadless, so the parity regression was effectively blessed instead of caught.
• Contributing context (if known): older Telegram paths in extensions/telegram/src/send.ts and extensions/telegram/src/draft-stream.ts already accepted the fallback tradeoff for forum threads, but the newer reply sender did not.

Regression Test Plan

• 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
• Scenario the test should lock in: a forum-topic send first attempts message_thread_id, gets 400: Bad Request: message thread not found, then retries once without message_thread_id and succeeds without runtime error logging.
• Why this is the smallest reliable guardrail: the bug lives in sendTelegramWithThreadFallback(), so the smallest durable guardrail is the delivery-layer test around that helper rather than a broader dispatcher workaround.
• Existing test that already covers this (if any): there was an existing forum-send test in this file, but it asserted the old incorrect behavior and was updated.
• If no new test is added, why not: N/A