openclaw - 💡(How to fix) Fix Telegram forum-topic follow-up delivery can lose topic context when OriginatingTo is flattened

Summary

Telegram forum-topic follow-up delivery can lose the specific topic context because some inbound Telegram topic code paths preserve MessageThreadId but flatten OriginatingTo back to plain telegram:<chatId> instead of a topic-qualified target like telegram:<chatId>:topic:<threadId>.

This appears to affect non-General topics in forum groups more than the General topic.

Observed behavior

• Direct chats work.
• General topic is mostly fine.
• Other Telegram forum topics in the same group can be inconsistent / "cranky".
• Replies can appear misplaced, invisible, or effectively delivered as if the topic context was lost.

Relevant config during repro

• messages.groupChat.visibleReplies = "automatic"
• channels.telegram.streaming.mode = "off"
• channels.telegram.replyToMode = "first"

These config changes improved other symptoms but did not fully solve non-General topic behavior.

Diagnosis

In the installed runtime (dist/bot-Ce301bOE.js on v2026.5.7), I found multiple inbound Telegram forum-topic paths where:

• MessageThreadId / threadSpec.id / resolvedThreadId were preserved
• but OriginatingTo or originatingTo was flattened to:
  • telegram:<chatId>

instead of preserving topic-qualified routing such as:

• telegram:<chatId>:topic:<threadId>

That creates a mismatch where downstream follow-up delivery can trust OriginatingTo and lose the topic target even though thread information still exists in the session context.

Concrete local patch/workaround

I locally patched these cases to preserve topic-qualified routing:

1. Main inbound session context

   • from OriginatingTo: \telegram:${chatId}``
   • to OriginatingTo: buildTelegramRoutingTarget(chatId, threadSpec)

2. Mention-skip/internal hook context

   • from originatingTo: \telegram:${chatId}``
   • to originatingTo: resolvedThreadId != null ? \telegram:${chatId}:topic:${resolvedThreadId}` : `telegram:${chatId}``

3. Audio preflight context

   • from OriginatingTo: \telegram:${chatId}``
   • to OriginatingTo: replyThreadId != null ? \telegram:${chatId}:topic:${replyThreadId}` : `telegram:${chatId}``

After restart, the patched runtime was live and preserving topic-qualified OriginatingTo values.

Why this seems like a real bug

This is separate from the documented reaction-update limitation where Telegram reactions lack thread IDs and forum-group reactions route to :topic:1.

The issue here is in normal message/topic handling: thread metadata exists, but some inbound context builders flatten the origin route anyway.

Request

Please review Telegram forum-topic inbound context and follow-up delivery paths to ensure topic-qualified OriginatingTo is preserved consistently whenever threadSpec.id / resolvedThreadId / MessageThreadId is known.

It would also help to add a regression test covering non-General Telegram forum topics where follow-up delivery must remain bound to the original topic.