fix(telegram): preserve DM topic thread id for outbound media by ViffyGwaanl · Pull Request #7261 · openclaw/openclaw

ViffyGwaanl · 2026-02-02T16:20:45Z

Problem

In Telegram private chats with topics (Bot API 9.3+), async followup sends (routeReply/outbound → sendMessageTelegram) could drop message_thread_id when the DM thread id is 1, because sendMessageTelegram always treated thread ids as forum scope.

This causes outbound media/documents to land in the main DM window instead of the correct DM topic.

Fix

Detect private vs forum chat ids (positive chat id = private chat).
Build threadSpec with scope dm for private chats and forum otherwise, so buildTelegramThreadParams only omits id=1 for forum General topic, but keeps id=1 for DM topics.

Tests

Added tests covering DM message_thread_id=1 for media/doc sends and stickers.
Added tests ensuring forum General topic id=1 still omits message_thread_id.

This should fix delayed media/file replies in DM topics while preserving existing forum behavior.

Greptile Overview

Greptile Summary

This PR updates Telegram outbound sending to preserve message_thread_id=1 when sending to DM topics (Bot API 9.3+), while continuing to omit message_thread_id=1 for forum “General” topic sends. It does this by inferring whether the destination is a private chat vs a forum chat and passing a corresponding scope into buildTelegramThreadParams, plus adds unit tests covering DM topic id=1 for documents/media and stickers and forum general-topic omission.

Confidence Score: 3/5

This PR is likely safe to merge, but the DM-vs-forum detection and one of the new tests could allow regressions to slip through.
Core change is small and leverages existing buildTelegramThreadParams behavior, but it duplicates chat-id parsing logic in two places and can misclassify non-numeric chat IDs (e.g., @username). Additionally, the new “omit message_thread_id” test does not robustly assert absence of the field, reducing confidence that the intended regression is covered.
src/telegram/send.ts and src/telegram/send.returns-undefined-empty-input.test.ts

_{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!}

greptile-apps

_{2 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-02T16:22:33Z

src/telegram/send.ts

+  // Detect DM vs forum: positive chatId = DM, negative (especially -100...) = forum
+  const isPrivateChat = /^-?\d+$/.test(chatId) && Number.parseInt(chatId, 10) > 0;
+  const scope = isPrivateChat ? "dm" : "forum";


[P2] Avoid re-parsing chatId here; use target info or existing helpers.

normalizeChatId() already ensures numeric IDs match /^-?\d+$/ and parseTelegramTarget(to) typically contains enough structure to determine DM vs group/forum. Re-checking with RegExp + parseInt adds duplication and can misclassify non-numeric chat identifiers (e.g. @username) as forum even if they’re private/user chats; if messageThreadId is present in that case, we’ll send it with scope: "forum" and may incorrectly drop id=1.

Also appears in src/telegram/send.ts:705-708.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Prompt To Fix With AI

This is a comment left during a code review. Path: src/telegram/send.ts Line: 225:227 Comment: [P2] Avoid re-parsing `chatId` here; use target info or existing helpers. `normalizeChatId()` already ensures numeric IDs match `/^-?\d+$/` and `parseTelegramTarget(to)` typically contains enough structure to determine DM vs group/forum. Re-checking with `RegExp` + `parseInt` adds duplication and can misclassify non-numeric chat identifiers (e.g. `@username`) as `forum` even if they’re private/user chats; if `messageThreadId` is present in that case, we’ll send it with `scope: "forum"` and may incorrectly drop `id=1`. Also appears in `src/telegram/send.ts:705-708`. <sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub> How can I resolve this? If you propose a fix, please make it concise.

Done in dc9f363fd:

Removed regex/parseInt re-parsing and the as const assertion.

Added resolveTelegramThreadScope(chatId) that uses Number(chatId) (finite + >0 => dm, else forum). Non-numeric chat IDs (e.g. @username) are treated as non-DM.
This preserves DM topic thread ids (including message_thread_id=1) while still omitting forum general-topic thread id.

greptile-apps · 2026-02-02T16:22:34Z

src/telegram/send.returns-undefined-empty-input.test.ts

+  it("omits message_thread_id=1 for forum general topic", async () => {
+    const chatId = "-1001234567890";
+    const sendMessage = vi.fn().mockResolvedValue({
+      message_id: 59,
+      chat: { id: chatId },
+    });
+    const api = { sendMessage } as unknown as {
+      sendMessage: typeof sendMessage;
+    };
+
+    await sendMessageTelegram(chatId, "general topic message", {
+      token: "tok",
+      api,
+      messageThreadId: 1,
+    });
+
+    expect(sendMessage).toHaveBeenCalledWith(chatId, "general topic message", {
+      parse_mode: "HTML",
+      // message_thread_id should be omitted for forum general topic (id=1)
+    });


[P3] This assertion doesn’t actually verify omission of message_thread_id.

toHaveBeenCalledWith(chatId, "general topic message", { parse_mode: "HTML" }) will pass even if the implementation adds extra keys (e.g. message_thread_id: 1) unless you assert on the exact object or explicitly assert the absence via expect.objectContaining + checking keys. As written, the comment in the expected object is ignored at runtime.

Also impacts the sticker general-topic test at src/telegram/send.returns-undefined-empty-input.test.ts:748-766 (it uses undefined params, but could still miss cases where a params object is passed without message_thread_id).

Prompt To Fix With AI

This is a comment left during a code review. Path: src/telegram/send.returns-undefined-empty-input.test.ts Line: 599:618 Comment: [P3] This assertion doesn’t actually verify omission of `message_thread_id`. `toHaveBeenCalledWith(chatId, "general topic message", { parse_mode: "HTML" })` will pass even if the implementation adds extra keys (e.g. `message_thread_id: 1`) unless you assert on the exact object or explicitly assert the absence via `expect.objectContaining` + checking keys. As written, the comment in the expected object is ignored at runtime. Also impacts the sticker general-topic test at `src/telegram/send.returns-undefined-empty-input.test.ts:748-766` (it uses `undefined` params, but could still miss cases where a params object is passed without `message_thread_id`). How can I resolve this? If you propose a fix, please make it concise.

Updated the tests in dc9f363fd:

Use expect.objectContaining({ parse_mode: "HTML" }) for the params bag.

Explicitly assert message_thread_id is omitted: expect(params?.message_thread_id).toBeUndefined().
This makes the “forum general topic (id=1) omits thread id” behavior actually enforced.

ViffyGwaanl · 2026-02-03T14:29:06Z

更新：我已经把分支 rebase 到最新 main 并解决了冲突（冲突点在 tsconfig.json，上游最近合并了 tsconfig/ui 相关改动）。当前 PR 状态已变为 MERGEABLE，不再需要 ‘Resolve conflicts’ 操作。

我之前提到的 allowImportingTsExtensions / bun build 报错是基于当时那一轮 CI 的输出；上游最新 ci.yml 已调整（目前只跑 bun 的 vitest，不再跑 bun 的 tsc build），所以我这边没有再修改 tsconfig.json。

我已 force-push 更新分支并触发了新的 CI（现在 checks 都在 pending 跑）。谢谢！

ViffyGwaanl · 2026-02-03T15:25:00Z

CI update: Windows checks-windows (node, test) was failing with:

src/agents/pi-tools.workspace-paths.test.ts ENOENT during process.chdir(...) (worker crash + timeout)

I pushed a stabilization fix to the PR branch:

commit b8e9d20a6 (plus 1e2e4a995)

This wraps the CWD mutation in a helper that restores cwd best-effort (and resets to GITHUB_WORKSPACE after each test) so Windows runners don't crash if cwd becomes invalid.

New CI run has been triggered (run: 21636153404).

openclaw-barnacle bot added the channel: telegram Channel integration: telegram label Feb 2, 2026

greptile-apps bot reviewed Feb 2, 2026

View reviewed changes

ViffyGwaanl force-pushed the fix/telegram-dm-topic-media-threadid branch from 76487ec to 00b9b9e Compare February 3, 2026 14:47

openclaw-barnacle bot added the agents Agent runtime and tooling label Feb 3, 2026

ViffyGwaanl force-pushed the fix/telegram-dm-topic-media-threadid branch from b8e9d20 to bb15e98 Compare February 6, 2026 13:04

openclaw-barnacle bot removed the agents Agent runtime and tooling label Feb 6, 2026

gwaanl added 3 commits February 9, 2026 13:55

fix(telegram): preserve dm topic thread id for outbound media

ea97057

fix(telegram): infer thread scope from chat id for outbound sends

6005c89

chore(ci): rerun windows checks

eb1cd04

ViffyGwaanl force-pushed the fix/telegram-dm-topic-media-threadid branch from bb15e98 to eb1cd04 Compare February 9, 2026 05:55

Merge branch 'main' into fix/telegram-dm-topic-media-threadid

f6e2db5

openclaw-barnacle bot added the size: S label Feb 12, 2026

Merge branch 'main' into fix/telegram-dm-topic-media-threadid

ebc9a55

thewilloftheshadow force-pushed the main branch from bfc1ccb to f92900f Compare February 15, 2026 18:46

Lukavyi mentioned this pull request Feb 16, 2026

fix(telegram): restore thread_id=1 handling for DMs (regression from 19b8416a8) #10942

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(telegram): preserve DM topic thread id for outbound media#7261

fix(telegram): preserve DM topic thread id for outbound media#7261
ViffyGwaanl wants to merge 5 commits intoopenclaw:mainfrom
ViffyGwaanl:fix/telegram-dm-topic-media-threadid

ViffyGwaanl commented Feb 2, 2026 •

edited by greptile-apps bot

Loading

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot Feb 2, 2026

Uh oh!

ViffyGwaanl Feb 2, 2026

Uh oh!

greptile-apps bot Feb 2, 2026

Uh oh!

ViffyGwaanl Feb 2, 2026

Uh oh!

ViffyGwaanl commented Feb 3, 2026 •

edited

Loading

Uh oh!

ViffyGwaanl commented Feb 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Comments

Uh oh!

Conversation

ViffyGwaanl commented Feb 2, 2026 • edited by greptile-apps bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Fix

Tests

Greptile Overview

Greptile Summary

Confidence Score: 3/5

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

ViffyGwaanl Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

ViffyGwaanl Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

ViffyGwaanl commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ViffyGwaanl commented Feb 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Comments

ViffyGwaanl commented Feb 2, 2026 •

edited by greptile-apps bot

Loading

ViffyGwaanl commented Feb 3, 2026 •

edited

Loading