hermes - 💡(How to fix) Fix feat(feishu): opt-in reply_in_thread for @-mention replies to keep main chat clean

Summary

Today, when a user @-mentions the bot in the main Feishu group chat (not from inside an existing topic thread), the bot's reply is posted as a regular reply in the main chat. For agents that produce multi-message responses or display progress messages (e.g. execute_code, Interrupting/iteration heartbeats, multi-chunk long answers), this floods the main channel.

Feishu already supports a clean solution: passing reply_in_thread=true to the reply API makes the message automatically create a new topic thread if the source message isn't already in one. The bot's response (and all follow-up chunks) collapses into a [N replies] link in the main chat — see the Thread Introduction docs.

Current behavior

In gateway/platforms/feishu.py, _send_raw_message only sets reply_in_thread=true when the inbound message is already part of a thread:

reply_in_thread = bool((metadata or {}).get("thread_id"))

So @-mentions in the main chat → bot reply lives in the main chat.

Proposed behavior

Add a config option under messaging.feishu:

messaging:
  feishu:
    # Default: false (current behavior — only reply in thread when inbound is already in a thread)
    # true: any reply-style message (with reply_to) auto-creates a topic thread
    always_reply_in_thread: true

When the flag is on, _send_raw_message would compute:

reply_in_thread = bool(reply_to) if config.always_reply_in_thread else bool((metadata or {}).get("thread_id"))

Active push messages (no reply_to) take the create API branch and are unaffected — scheduled daily reports etc. still post normally to the main chat.

Why opt-in

Opt-in keeps the change fully backward compatible. Operators who run noisy agents in shared channels will turn it on; others keep current behavior.

Side effects (verified locally on snapshot c681687, patched to reply_in_thread = bool(reply_to) as a hardcoded test)

Related

• #9916 — bot replies leak out of P2P topic thread (the inverse direction; partially handled by current metadata.thread_id logic)

Happy to send a PR if this direction sounds right.