Summary

When replying inside a Feishu topic-enabled group chat, the agent would create a new topic/thread instead of staying inside the current one. This breaks multi-agent workflows where several bots operate in parallel within the same group — replies "cross" into stray topics.

Two root causes:

1. Inbound thread resolution — root_id was not used as a fallback for thread_id. When Feishu didn't provide thread_id directly, thread context was silently lost.
2. Reply failure fallback — when a threaded reply failed (target withdrawn/deleted, API error codes 230011 / 231003), the code fell back to im.v1.message.create. In topic-enabled groups this spawns a brand-new topic instead of staying in the thread.

Changes

gateway/platforms/feishu.py (+13 / −1)

• Resolve thread_id with root_id as fallback (thread_id || root_id)
• Add root_id to the reply_to_message_id fallback chain (parent_id → upper_message_id → root_id)
• Guard the reply-to-create fallback: when inside a thread (metadata.thread_id is set), skip the fallback and return the error response as-is — avoids spawning a new topic

gateway/platforms/base.py (+21 / −3)

• In three outbound reply paths (command dispatch, inline bypass, main response delivery), prefer event.reply_to_message_id over event.message_id when:
  • Platform is Feishu and
  • Inside a thread (event.source.thread_id) and
  • reply_to_message_id is available
• This ensures the Feishu reply API targets the correct message within the topic card

Test plan

• In a Feishu topic-enabled group, send a message inside an existing topic card — agent should reply within the same topic
• Send a longer request that takes minutes to process — agent should still reply within the topic
• Open multiple topics in parallel with different agents — replies should not cross into wrong topics
• Verify non-topic chats (DMs, non-topic groups) still work normally — the reply-to-create fallback should still apply there