PR #78207: fix: keep Feishu group mentions replyable

• Repository: openclaw/openclaw
• Author: bryce-d-greybeard
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/78207

Description (problem / solution / changelog)

Fixes #78204.

Summary

• Default Feishu group turns now keep automatic source replies when no visible-replies preference is explicitly configured.
• Explicit messages.groupChat.visibleReplies / messages.visibleReplies settings are still honored, including message_tool.
• Added regression coverage for Feishu group dispatch and reply dispatcher option propagation.

Tests

• git diff --check
• /tank/development/linus/openclaw/node_modules/.bin/oxfmt --check extensions/feishu/src/bot.ts extensions/feishu/src/reply-dispatcher.ts extensions/feishu/src/bot.test.ts extensions/feishu/src/reply-dispatcher.test.ts
• Targeted Feishu vitest attempted with parent repo node_modules, but blocked before tests by missing local @openclaw/fs-safe/config from src/infra/fs-safe-defaults.ts.
• PATH="/tmp/openclaw-pnpm-shim:$PATH" node scripts/check-changed.mjs passed conflict/changelog/extension wildcard/plugin-sdk wildcard/duplicate lanes; failed typecheck on unrelated existing missing @openclaw/fs-safe/* and strictness diagnostics outside this patch.

Changed files

• extensions/feishu/src/bot.test.ts (modified, +47/-0)
• extensions/feishu/src/bot.ts (modified, +7/-0)
• extensions/feishu/src/reply-dispatcher.test.ts (modified, +12/-0)
• extensions/feishu/src/reply-dispatcher.ts (modified, +4/-0)

PR #78230: fix(feishu): default group source replies to automatic when not configured

• Repository: openclaw/openclaw
• Author: Beandon13
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/78230

Description (problem / solution / changelog)

Fixes #78204.

Root cause

Feishu group dispatch goes through the cross-platform reply pipeline, which in resolveSourceReplyDeliveryMode defaults groups/channels to message_tool_only whenever messages.groupChat.visibleReplies / messages.visibleReplies are unset. That mode only delivers the agent's reply if the model calls the message tool. Models rarely call that tool in Feishu groups, so the symptom in #78204 is exactly what the reporter sees: the bot shows the typing indicator after a group mention, the indicator disappears, and no reply ever lands. DMs are unaffected because their default already resolves to automatic.

What the fix does

• In handleFeishuMessage, compute defaultSourceReplyDeliveryMode = \"automatic\" for group dispatch whenever the user has not explicitly configured visibleReplies, and forward it to both createFeishuReplyDispatcher call sites (single-agent and broadcast).
• createFeishuReplyDispatcher accepts the new defaultSourceReplyDeliveryMode parameter and propagates it onto replyOptions.sourceReplyDeliveryMode. The auto-reply pipeline treats that as a requested mode and short-circuits the group default.
• Explicit messages.groupChat.visibleReplies (including \"message_tool\") and explicit messages.visibleReplies continue to win — the override is only applied when the user has configured nothing.

Tests

• reply-dispatcher.test.ts:
  • new positive case: dispatcher propagates sourceReplyDeliveryMode: \"automatic\" when caller opts in.
  • new negative case: dispatcher does not set sourceReplyDeliveryMode when caller does not opt in.
• bot.test.ts:
  • asserted that the existing group authorization test now sees defaultSourceReplyDeliveryMode: \"automatic\" on the dispatcher invocation.
  • new test: explicit messages.groupChat.visibleReplies = \"message_tool\" keeps the dispatcher call clean of the default override.

Real behavior proof

Unit tests only. Local vitest blocked before tests by the @openclaw/fs-safe/config import gap shared by the other PRs in this repo. The change is targeted (default applied only when both isGroup and visibleReplies-unset hold) and the new tests cover both branches plus the explicit-config opt-out.

Changed files

• extensions/feishu/src/bot.test.ts (modified, +51/-0)
• extensions/feishu/src/bot.ts (modified, +16/-0)
• extensions/feishu/src/reply-dispatcher.test.ts (modified, +29/-0)
• extensions/feishu/src/reply-dispatcher.ts (modified, +13/-0)

PR #78310: fix(feishu): keep topic sessions stable

• Repository: openclaw/openclaw
• Author: steipete
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/78310

Description (problem / solution / changelog)

Summary

• Problem: Feishu native topic starter events can arrive without thread_id, while later topic replies include the canonical omt_* thread id.
• Why it matters: with groupSessionScope: "group_topic" / "group_topic_sender", the first turn can route by message_id and follow-ups by thread_id, splitting one Feishu topic into multiple OpenClaw sessions.
• What changed: Feishu hydrates a missing native topic starter thread_id with getMessageFeishu before resolving the group session route.
• What did NOT change: group visible-reply defaults/message-tool behavior. PR #78310 was narrowed to topic hydration only.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #78262
• Related #78230
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: Feishu native topic starter and follow-up messages resolve to the same topic session key.
• Real environment tested: Blacksmith Testbox via Crabbox, Linux CI-equivalent checkout.
• Exact steps or command run after this patch:
  • pnpm test extensions/feishu/src/bot.test.ts -- -t "hydrates missing native topic thread_id|keeps topic session key stable"
  • pnpm check:changed
• Evidence after fix:
  • Local focused test: 2 passed, 59 skipped.
  • Crabbox check:changed: tbx_01kqxytxdcy4hky5j0sses6237, exit 0.
• Observed result after fix: the new regression test hydrates omt_native_topic before routing the starter event, and both starter/follow-up route to oc-group:topic:omt_native_topic.
• What was not tested: live Feishu tenant message round-trip.
• Before evidence: existing test coverage showed first-turn topic sessions could fall back to the starter message_id when no thread_id was available.

Root Cause (if applicable)

• Root cause: Feishu route/session resolution happened before any API hydration that could recover a missing native topic thread_id.
• Missing detection / guardrail: tests covered normal group reply-root stability but not native topic_group starter events missing thread_id.
• Contributing context (if known): #78230 mixed this with visible-reply behavior; this PR deliberately keeps only the proven topic-session fix.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/feishu/src/bot.test.ts
• Scenario the test should lock in: a native Feishu topic starter missing thread_id is hydrated before route resolution, and its follow-up with thread_id resolves to the same group_topic peer.
• Why this is the smallest reliable guardrail: it exercises Feishu inbound routing directly with mocked Feishu message hydration.
• Existing test that already covers this (if any): adjacent topic-session stability tests cover normal group reply roots.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

Feishu topic-mode group sessions are more stable when native topic starter events omit thread_id.

Diagram (if applicable)

Before:
Feishu topic starter without thread_id -> route by message_id
Feishu topic follow-up with thread_id -> route by omt_* -> split session

After:
Feishu topic starter without thread_id -> hydrate omt_* -> route by omt_*
Feishu topic follow-up with thread_id -> route by same omt_* -> same session

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? Yes
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: Feishu topic-scoped starter events may call existing Feishu message lookup to hydrate thread_id; this uses the already configured Feishu account and only runs for native topic_group topic-scoped routing when the event omitted thread_id.

Repro + Verification

Environment

• OS: macOS local targeted test; Linux Blacksmith Testbox via Crabbox.
• Runtime/container: Node/pnpm repo test runtime.
• Model/provider: mocked test runtime.
• Integration/channel (if any): Feishu plugin.
• Relevant config (redacted): channels.feishu.groups.oc-group.groupSessionScope: "group_topic", replyInThread: "enabled".

Steps

1. Dispatch a native Feishu topic_group starter event with no thread_id.
2. Mock getMessageFeishu to return threadId: "omt_native_topic".
3. Dispatch a follow-up event carrying thread_id: "omt_native_topic".

Expected

Both turns route to oc-group:topic:omt_native_topic.

Actual

Matches expected in focused test and Crabbox changed gate.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: Feishu native topic starter hydration and follow-up route stability.
• Edge cases checked: existing first-turn/follow-up topic stability test still passes.
• What you did not verify: live Feishu tenant round-trip.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A.

Risks and Mitigations

• Risk: extra Feishu message lookup on native topic starters with missing thread_id.
  • Mitigation: narrow condition; failures are logged and existing fallback behavior remains.

Changed files

• CHANGELOG.md (modified, +1/-0)
• docs/channels/feishu.md (modified, +4/-3)
• extensions/feishu/src/bot.test.ts (modified, +69/-0)
• extensions/feishu/src/bot.ts (modified, +56/-1)