← Back to PRs

#19793: feat(feishu): reply-in-thread, parallel group sessions, and fire-and-forget handling [AI-assisted]

by yinsn open 2026-02-18 05:21 View on GitHub →
channel: feishu size: M
## Summary Four related improvements to the Feishu extension that significantly improve group chat UX, especially for active groups with multiple concurrent users. ### Changes 1. **Always reply in thread** (`send.ts`) — Add `reply_in_thread: true` to all `im.message.reply` API calls (both text and card messages). Bot responses stay contained in threads instead of cluttering the main group timeline. 2. **Parallel group timeline sessions** (`bot.ts`) — When `topicSessionMode` is enabled, use `ctx.rootId ?? ctx.messageId` as the topic key instead of only `ctx.rootId`. Thread replies share a session by `rootId` (existing behavior), while timeline messages each get their own session via `messageId`, enabling true parallel processing. 3. **DM topic session isolation** (`bot.ts`) — Add topic session support for DM conversations. When a DM message has a `rootId` and `topicSessionMode` is enabled, it gets its own topic-scoped session. 4. **Reply to thread root** (`bot.ts`) — Change `replyToMessageId` from `ctx.messageId` to `ctx.rootId || ctx.messageId` so replies within a thread always target the root message, avoiding nested sub-threads. 5. **Fire-and-forget message handling** (`monitor.ts`) — Always use fire-and-forget (`.catch()` without `await`) regardless of the `fireAndForget` flag. Combined with per-message sessions, this is safe and dramatically improves throughput. ### Motivation Without these changes, bot behavior in group chats has several pain points: - Replies appear on the main timeline, cluttering the chat - Messages are processed sequentially — a 30s response blocks the next message - Replying inside a thread creates a nested sub-thread - Timeline messages in the same group share a single session, causing context mixing ### Testing - Tested with `topicSessionMode: "enabled"` in group config - Verified in production Feishu group with multiple concurrent users - Lightly tested (no automated test suite run) Closes #19784 🤖 Generated with [Claude Code](https://claude.ai/code) <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR improves Feishu group chat UX with five changes: always reply in thread, parallel group timeline sessions via `topicSessionMode`, DM topic session isolation, reply-to-thread-root targeting, and always-fire-and-forget message handling. - **Race condition risk in `monitor.ts`**: The `fireAndForget` conditional was removed so all messages are now fire-and-forget, but the comment's safety assumption ("each message gets its own session") only holds when `topicSessionMode` is `"enabled"`. When disabled (the default), group messages share a session and parallel dispatch may cause context mixing. - **`reply_in_thread: true` in DMs**: The flag is added unconditionally in `send.ts`, which affects DM conversations too — this may be unintended. - **Dead code**: The `fireAndForget` parameter in `monitor.ts` is no longer read but is still declared, destructured, and passed by callers. <h3>Confidence Score: 2/5</h3> - This PR introduces a race condition for the default configuration and an unconditional behavior change for DMs that may be unintended. - The fire-and-forget change in monitor.ts removes the sequential processing guarantee for websocket mode when topicSessionMode is disabled (the default). This is a correctness regression for the common case. The reply_in_thread flag applied to DMs is also a concern since it changes DM UX without clear intent. - `extensions/feishu/src/monitor.ts` (race condition with default config), `extensions/feishu/src/send.ts` (unconditional DM threading) <sub>Last reviewed commit: ed953f7</sub> <!-- greptile_other_comments_section --> <sub>(2/5) Greptile learns from your feedback when you react with thumbs up/down!</sub> <!-- /greptile_comment -->

Most Similar PRs