openclaw - ✅(Solved) Fix Feishu: topic session key mismatch — first message uses messageId, subsequent messages use thread_id [1 pull requests, 5 comments, 4 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#78262Fetched 2026-05-07 03:39:03
View on GitHub
Comments
5
Participants
4
Timeline
16
Reactions
2
Timeline (top)
commented ×5mentioned ×3subscribed ×3cross-referenced ×2

When groupSessionScope: "group_topic" is configured for a Feishu account, the session key for the first message in a topic thread differs from subsequent messages, causing session splitting.

  • First message in a topic: session key uses messageId (e.g., feishu:group:oc_xxx:om_xxx)
  • Subsequent replies in the same topic: session key uses thread_id / topic_id

This results in the agent losing context after the first message, as each gets assigned to a different session.

Root Cause

When groupSessionScope: "group_topic" is configured for a Feishu account, the session key for the first message in a topic thread differs from subsequent messages, causing session splitting.

  • First message in a topic: session key uses messageId (e.g., feishu:group:oc_xxx:om_xxx)
  • Subsequent replies in the same topic: session key uses thread_id / topic_id

This results in the agent losing context after the first message, as each gets assigned to a different session.

Fix Action

Fixed

PR fix notes

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

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)
RAW_BUFFERClick to expand / collapse

Description

When groupSessionScope: "group_topic" is configured for a Feishu account, the session key for the first message in a topic thread differs from subsequent messages, causing session splitting.

  • First message in a topic: session key uses messageId (e.g., feishu:group:oc_xxx:om_xxx)
  • Subsequent replies in the same topic: session key uses thread_id / topic_id

This results in the agent losing context after the first message, as each gets assigned to a different session.

Expected Behavior

All messages in the same Feishu topic thread should resolve to the same session key, regardless of whether it is the first message (which creates the thread) or a subsequent reply.

Steps to Reproduce

  1. Configure groupSessionScope: "group_topic" for a Feishu account
  2. Send a message in a Feishu group (this creates a new topic)
  3. Reply to that message in the same thread
  4. Observe that the first message and the reply land in different sessions

Context

  • PR #29788 attempted to fix this ("keep first-turn topic keys stable across thread creation") but the fix does not fully cover this case
  • The group_topic feature was introduced in PR #17798
  • Without group_topic set (default "group"), the entire group shares one session so the issue does not manifest

Environment

  • OpenClaw version: 2026.4.23+
  • Channel: Feishu
  • Config: groupSessionScope: "group_topic"

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Feishu: topic session key mismatch — first message uses messageId, subsequent messages use thread_id [1 pull requests, 5 comments, 4 participants]