openclaw - 💡(How to fix) Fix [Feishu] group_topic session splits when different root_id formats (omt_ vs om_) used for same topic [1 comments, 2 participants]

Bug: Feishu group_topic session splits into two sessions for same topic

Environment

• OpenClaw (latest)
• Channel: Feishu/Lark
• Config: groupSessionScope: "group_topic" on a specific group

Steps to Reproduce

1. Configure a Feishu group with groupSessionScope: "group_topic" and replyInThread: "enabled"
2. In a Feishu 话题群 (topic group), Person A sends a message mentioning the bot — this creates a new topic thread
3. Person B (or the same person) replies inside that same topic thread, mentioning the bot again

Expected Behavior

Both messages are in the same topic thread → same session key → same conversation context

Actual Behavior

Two different sessions are created:

• Message 1 (topic creator): ...group:<chatId>:topic:omt_1a89bd796d0f1c93 — topicId prefix is omt_
• Message 2 (reply inside topic): ...group:<chatId>:topic:om_x100b51f715c93ca0b3f5db08eaf7497 — topicId prefix is om_

Root Cause (traced via source)

In monitor.js, session key is built from event.message.root_id:

rootId: event.message.root_id || void 0,
// ...
const topicScope = normalizedRootId ?? normalizedThreadId ?? ...

Feishu returns two different root_id formats for the same topic:

• The topic-creator message has root_id = omt_xxx (topic object ID)
• Replies inside the topic have root_id = om_xxx (the creator message's message ID)

These two values are different strings → different topicScope → different session keys.

Suggested Fix

Prefer thread_id over root_id as the canonical topic key when building the session scope. In Feishu topic groups, thread_id consistently carries the omt_xxx topic object ID across all messages in the same thread, while root_id varies between omt_xxx (topic creator) and om_xxx (replies).

// Instead of:
const topicScope = normalizedRootId ?? normalizedThreadId ?? ...

// Consider:
const topicScope = normalizedThreadId ?? normalizedRootId ?? ...

Workaround

Use groupSessionScope: "group_sender" instead — each sender gets their own session regardless of topic, avoiding the split.