Skip to content

feat(feishu): add FEISHU_AUTO_THREAD for automatic thread replies - #11405

Closed
nick2781 wants to merge 1 commit into
NousResearch:mainfrom
nick2781:feat/feishu-auto-thread
Closed

feat(feishu): add FEISHU_AUTO_THREAD for automatic thread replies#11405
nick2781 wants to merge 1 commit into
NousResearch:mainfrom
nick2781:feat/feishu-auto-thread

Conversation

@nick2781

Copy link
Copy Markdown

Summary

  • Adds FEISHU_AUTO_THREAD env var (default: false) that, when enabled, makes all Feishu replies land inside threads automatically
  • Each new inbound message creates a new thread, isolating conversation context per thread and preventing unrelated conversations from mixing and exhausting the context window
  • Works for both streaming and non-streaming reply paths

How it works

Feishu's reply API supports a reply_in_thread flag, but the create API does not. Many code paths (streaming, agent tool calls) use create because they don't have a reply_to message ID.

This PR:

  1. Tracks the last inbound message_id per chat_id in FeishuAdapter
  2. In _send_raw_message, when FEISHU_AUTO_THREAD=true and no reply_to is provided, automatically uses the tracked message ID — routing through the reply API with reply_in_thread=true
  3. Passes an initial reply_to to GatewayStreamConsumer so streaming replies also land in threads

Configuration

# In ~/.hermes/.env
FEISHU_AUTO_THREAD=true

Defaults to false — no behavior change for existing users.

Test plan

  • Verified in private chat: replies appear inside threads
  • Verified reply_in_thread=true is set in the reply API call
  • Verified backward compatibility: without FEISHU_AUTO_THREAD, behavior is unchanged

🤖 Generated with Claude Code

When FEISHU_AUTO_THREAD=true, all Feishu replies are sent with
reply_in_thread=true, causing Feishu to automatically create a
thread for each new conversation. This isolates session context
per thread, preventing unrelated conversations from mixing and
exhausting the context window.

Implementation:
- Track last inbound message_id per chat_id in FeishuAdapter
- When auto_thread is on and no reply_to is provided, use the
  tracked message_id so the reply API (which supports
  reply_in_thread) is used instead of the create API
- Pass initial reply_to to GatewayStreamConsumer for streaming
  replies to also land in threads
- Env var defaults to false for backward compatibility

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@nick2781

Copy link
Copy Markdown
Author

@teknium1 Is there somebody can do the code review?

@alt-glitch alt-glitch added type/feature New feature or request P2 Medium — degraded but workaround exists platform/feishu Feishu / Lark adapter comp/gateway Gateway runner, session dispatch, delivery labels Apr 23, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Related to #9118 (Feishu auto-thread PR) and #9154 (feature request). May overlap — check for merge conflicts.

@teknium1

Copy link
Copy Markdown
Contributor

Thanks for the clear Feishu threading investigation and for covering both ordinary and streaming reply paths.

This automated hermes-sweeper review is closing the PR under the standing configuration policy:

  • The PR introduces FEISHU_AUTO_THREAD as a user-facing behavioral switch and documents setting it in .env (gateway/platforms/feishu.py, PR head 5e413166dc1c).
  • AGENTS.md:102-107 requires non-secret behavior settings and feature flags to use config.yaml, not new environment-variable configuration.
  • The current gateway has a plugin-owned YAML configuration path (gateway/config.py:1252-1287); Feishu registers its bridge in plugins/platforms/feishu/adapter.py:5618-5654.
  • Related PR feat(gateway): Feishu auto-thread and topic-based session routing #9118 was already closed on the same env-var-for-config policy for its FEISHU_AUTO_THREAD implementation.

Please re-scope a follow-up around Feishu YAML configuration through the plugin bridge, preserving thread_id as the topic identity. This is a design-direction decision, not a judgment on the implementation quality.


Automated hermes-sweeper review.


Closed as not-planned per standing maintainer policy (env-var-for-config). This is a design-direction decision, not a code-quality judgment — see the Contribution Rubric in AGENTS.md for what the project is looking for. If you believe this policy was misapplied to your change, comment here and a maintainer will take a look.

@teknium1 teknium1 closed this Jul 12, 2026
@teknium1 teknium1 added the sweeper:not-planned Sweeper: closed per standing maintainer policy (design direction) label Jul 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/gateway Gateway runner, session dispatch, delivery P2 Medium — degraded but workaround exists platform/feishu Feishu / Lark adapter sweeper:not-planned Sweeper: closed per standing maintainer policy (design direction) type/feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants