Bug Description

In a Feishu/Lark topic-mode group, Hermes can split one logical interaction across topics: final responses usually stay in the original topic, but intermediate streaming/tool-progress/status messages can appear as new top-level topic messages.

We reproduced this in a Feishu group topic. This matches the behavior discussed in #6969 and #7734, and the fixes proposed in #13077 / #16603.

Steps to Reproduce

1. Configure Hermes gateway with Feishu/Lark WebSocket integration.
2. Open an existing topic/thread in a Feishu topic-mode group.
3. Mention Hermes in that topic and ask a question that triggers tool use or streamed/intermediate status output.
4. Observe where the tool progress / interim messages are posted.

Expected Behavior

All outbound messages for the request should remain scoped to the original Feishu topic/thread:

• first streamed response chunk
• tool-progress messages
• interim assistant/status messages
• approval/progress cards
• final response

Actual Behavior

Some intermediate messages are sent without a topic/thread anchor. Feishu treats those sends as message.create at the chat level, so they can appear as new topics instead of replies inside the original topic.

Root Cause Hypothesis

There are two related paths:

1. GatewayStreamConsumer creates the first streamed message before it has a platform message_id, so the first send can go out without reply_to.
2. FeishuAdapter._send_raw_message() ignores metadata["thread_id"] when reply_to is absent and always creates with receive_id_type="chat_id".

For Feishu topic threads, message.reply with the inbound message_id, or message.create with receive_id_type="thread_id", keeps the message in the existing topic.

Related Work

• Related issue: Feishu topic progress messages create new topics instead of staying in the original topic #6969
• Related issue: [Bug]: Title: Two issues with the Feishu plugin #7734
• Related PR: fix(gateway): stream consumer first message drops thread context #13077
• Related PR: fix(feishu): post into existing topic thread when reply_to is absent #16603

Proposed Fix

I will submit a PR that:

• passes the inbound message id into GatewayStreamConsumer only for Feishu threaded runs, so the first streaming send can reply to the topic message;
• makes Feishu message.create use receive_id_type="thread_id" when reply_to is absent but metadata["thread_id"] is present;
• adds regression tests for both paths.

Test Plan

• python -m pytest tests/gateway/test_feishu.py tests/gateway/test_stream_consumer.py -q