Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug] Feishu bindings with accountId or group peer.kind not working [1 pull requests, 4 comments, 2 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#43633•Fetched 2026-04-08 00:16:35
View on GitHub
Comments
4
Participants
2
Timeline
5
Reactions
0
Author
leonzoppleonzopp
Participants
CrazyBoyMCrazyBoyMleonzoppleonzopp
Timeline (top)
commented ×3cross-referenced ×1labeled ×1

Feishu bindings not working - messages routed to default agent instead of configured agentId

Root Cause

Feishu bindings not working - messages routed to default agent instead of configured agentId

Fix Action

Fix / Workaround

Logs: feishu[main]: received message from ... in oc_nova_group (group) feishu[main]: dispatching to agent (session=agent:main:feishu:group:oc_nova_group)

PR fix notes

PR #43708: Fix Feishu route matching for legacy lark bindings

Description (problem / solution / changelog)

Summary

  • Problem: Feishu inbound routing can silently fall back to the default agent when bindings still use the legacy channel alias lark.
  • Why it matters: accountId + peer.kind=group bindings appear valid but never match, so group/account routing breaks for existing configs.
  • What changed: normalized routing channel keys in resolveAgentRoute and evaluated binding indexing to treat legacy lark as canonical feishu.
  • What did NOT change (scope boundary): no changes to binding precedence, peer matching semantics, or Feishu message parsing.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor
  • 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 #43633
  • Related #16354
  • Related #39382

User-visible / Behavior Changes

  • Existing bindings with match.channel: "lark" now match Feishu inbound routing (channel: "feishu") and route to the configured agent instead of default fallback.

Security Impact (required)

  • New permissions/capabilities? (No)
  • Secrets/tokens handling changed? (No)
  • New/changed network calls? (No)
  • Command/tool execution surface changed? (No)
  • Data access scope changed? (No)
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS: macOS
  • Runtime/container: Node.js v22
  • Model/provider: N/A (routing unit tests)
  • Integration/channel (if any): Feishu
  • Relevant config (redacted): route binding with match.channel: "lark", match.accountId: "main", match.peer: { kind: "group", id: "oc_nova_group" }

Steps

  1. Configure a route binding using legacy match.channel: "lark" for a Feishu group/account.
  2. Resolve inbound route for channel feishu, account main, and matching group peer.
  3. Observe route selection.

Expected

  • Binding should match and route to configured agent.

Actual

  • Before fix: route falls back to default agent.
  • After fix: route matches binding (matchedBy: "binding.peer").

Evidence

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

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios:
    • pnpm exec vitest run src/routing/resolve-route.test.ts passes including new regression test.
    • Runtime probe now resolves lark binding with Feishu input to configured agent (agent:nova).
  • Edge cases checked:
    • Existing feishu bindings still match unchanged.
    • Group/channel peer compatibility behavior remains unchanged.
  • What you did not verify:
    • Live Feishu webhook traffic in a real tenant.

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:

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly:
    • Revert commit fe3fc569a.
  • Files/config to restore:
    • src/routing/resolve-route.ts
    • src/routing/resolve-route.test.ts
  • Known bad symptoms reviewers should watch for:
    • Route matches unexpectedly changing for non-Feishu alias channels.

Risks and Mitigations

  • Risk: Channel normalization path in resolver now canonicalizes legacy alias.
    • Mitigation: Added focused regression test and kept scope to channel key normalization only.

Changed files

  • src/routing/resolve-route.test.ts (modified, +68/-0)
  • src/routing/resolve-route.ts (modified, +11/-2)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Summary

Feishu bindings not working - messages routed to default agent instead of configured agentId

Steps to reproduce

  1. Configure multiple Feishu accounts (main, nova, atlas) in openclaw.json
  2. Add bindings with peer.kind=group for different group IDs
  3. Send message from a group
  4. Observe: messages routed to agent:main instead of agent:nova/atlas

Expected behavior

Messages should be routed to agent specified in bindings (e.g., agent:nova for Nova group)

Actual behavior

All messages routed to default agent (agent:main:main)

Logs: feishu[main]: received message from ... in oc_nova_group (group) feishu[main]: dispatching to agent (session=agent:main:feishu:group:oc_nova_group)

OpenClaw version

2026.3.8

Operating system

macOS 25.3.0

Install method

npm global

Model

minimax/text-01

Provider / routing chain

openclaw -> minimax

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

Fix Plan

The issue seems to be related to incorrect routing of Feishu messages to the default agent instead of the configured agentId. To fix this, we need to update the openclaw.json configuration file to correctly map the Feishu group IDs to their respective agent IDs.

Steps to Fix

  • Update the openclaw.json file to include the correct agentId for each Feishu group ID:
{
  "bindings": [
    {
      "peer": {
        "kind": "group",
        "id": "oc_nova_group"
      },
      "agentId": "agent:nova"
    },
    {
      "peer": {
        "kind": "group",
        "id": "oc_atlas_group"
      },
      "agentId": "agent:atlas"
    }
  ]
}
  • Restart the OpenClaw service to apply the changes.

Verification

To verify that the fix worked, send a message from each Feishu group and check the logs to ensure that the messages are being routed to the correct agent ID.

Example Code

No additional code changes are required, only updates to the openclaw.json configuration file. However, you can add a check in your code to ensure that the agentId is correctly set for each Feishu group ID:

const bindings = [
  {
    peer: {
      kind: 'group',
      id: 'oc_nova_group'
    },
    agentId: 'agent:nova'
  },
  {
    peer: {
      kind: 'group',
      id: 'oc_atlas_group'
    },
    agentId: 'agent:atlas'
  }
];

// Check if the agentId is correctly set for each group ID
bindings.forEach(binding => {
  if (!binding.agentId) {
    console.error(`Agent ID not set for group ${binding.peer.id}`);
  }
});

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…

FAQ

Expected behavior

Messages should be routed to agent specified in bindings (e.g., agent:nova for Nova group)

#api#ssr#installation#tensor shape#autograd error#output truncation#response parsing#generation error#database connection#vector store

Still need to ship something?

×6

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

Back to top recommendations

TRENDING