openclaw - 💡(How to fix) Fix [Bug]: Binding 匹配在并发场景下错乱 - Feishu 多群消息路由失败 [2 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#50127Fetched 2026-04-08 00:58:53
View on GitHub
Comments
2
Participants
2
Timeline
5
Reactions
0
Timeline (top)
labeled ×2closed ×1commented ×1reopened ×1

Code Example

{
     "bindings": [
       {"agentId": "sales", "match": {"channel": "feishu", "accountId": "main", "peer": {"kind": "group", "id": "oc_541..."}}},
       {"agentId": "finance", "match": {"channel": "feishu", "accountId": "main", "peer": {"kind": "group", "id": "oc_728..."}}},
       {"agentId": "warehouse", "match": {"channel": "feishu", "accountId": "main", "peer": {"kind": "group", "id": "oc_6b8..."}}},
       {"agentId": "main", "match": {"channel": "feishu", "accountId": "main"}}
     ]
   }

---

$ openclaw agents list --bindings

- sales (销售助手)
  Routing rules:
    - feishu peer=group:oc_5417465dfb4d698a258cfd23d6da035f

- finance (财务助手)
  Routing rules:
    - feishu peer=group:oc_72898e6c2eb539a6d7d444041aee6f59

- warehouse (综合服务助手)
  Routing rules:
    - feishu peer=group:oc_6b83f08fa997520d1d2629ca32911f9a

- main (默认)
  Routing rules:
    - feishu

### Actual behavior

## 现象分析

-**单群顺序测试**: 每个群都能正确路由到对应 Agent
-**多群并发测试**: 如果群A的消息还没回复完就发送群B的消息,群B会变成 Main Agent 兜底
- 怀疑是 `resolveAgentRoute` 在并发场景下有状态竞争问题,或者会话缓存存在某种全局状态污染

## 可能的解决方案

1. 检查 `core.channel.routing.resolveAgentRoute` 函数是否在并发场景下正确隔离状态
2. 检查是否有全局缓存/状态被错误共享
3. 确保每个消息路由上下文独立


### OpenClaw version

2026.3.12

### Operating system

Windows 10 (x64)

### Install method

_No response_

### Model

kimi k2.5

### Provider / routing chain

- **插件**: @larksuite/openclaw-lark@2026.3.15 - **Model**: kimi-coding/k2p5

### Config file / key location

_No response_

### Additional provider/model setup details

_No response_

### Logs, screenshots, and evidence
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Summary

问题描述

当多个飞书群同时有消息在处理时(并发场景),binding 匹配会失败,后续群的消息被错误地路由到默认 agent(main),而不是绑定的特定 agent。

复现步骤

  1. 配置多个 binding,每个群绑定不同 agent:
    {
      "bindings": [
        {"agentId": "sales", "match": {"channel": "feishu", "accountId": "main", "peer": {"kind": "group", "id": "oc_541..."}}},
        {"agentId": "finance", "match": {"channel": "feishu", "accountId": "main", "peer": {"kind": "group", "id": "oc_728..."}}},
        {"agentId": "warehouse", "match": {"channel": "feishu", "accountId": "main", "peer": {"kind": "group", "id": "oc_6b8..."}}},
        {"agentId": "main", "match": {"channel": "feishu", "accountId": "main"}}
      ]
    }

Steps to reproduce

在群A(销售助手群)发送消息 @ Bot 3. 不等回复完成,立即在群B(财务助手群)发送消息 @ Bot 4. 群B的消息会被 main agent 处理,而不是绑定的 finance agent

预期行为

群B的消息应该由 agent:finance 处理

实际行为

群B的消息被 agent:main 兜底处理

环境信息

  • OpenClaw 版本: 2026.3.12
  • 操作系统: Windows 10 (x64)
  • Node.js: v24.14.0
  • 插件: @larksuite/[email protected]
  • Model: kimi-coding/k2p5

Expected behavior

已验证的配置

$ openclaw agents list --bindings

- sales (销售助手)
  Routing rules:
    - feishu peer=group:oc_5417465dfb4d698a258cfd23d6da035f

- finance (财务助手)
  Routing rules:
    - feishu peer=group:oc_72898e6c2eb539a6d7d444041aee6f59

- warehouse (综合服务助手)
  Routing rules:
    - feishu peer=group:oc_6b83f08fa997520d1d2629ca32911f9a

- main (默认)
  Routing rules:
    - feishu

### Actual behavior

## 现象分析

- ✅ **单群顺序测试**: 每个群都能正确路由到对应 Agent
- ❌ **多群并发测试**: 如果群A的消息还没回复完就发送群B的消息,群B会变成 Main Agent 兜底
- 怀疑是 `resolveAgentRoute` 在并发场景下有状态竞争问题,或者会话缓存存在某种全局状态污染

## 可能的解决方案

1. 检查 `core.channel.routing.resolveAgentRoute` 函数是否在并发场景下正确隔离状态
2. 检查是否有全局缓存/状态被错误共享
3. 确保每个消息路由上下文独立


### OpenClaw version

2026.3.12

### Operating system

Windows 10 (x64)

### Install method

_No response_

### Model

kimi k2.5

### Provider / routing chain

- **插件**: @larksuite/[email protected] - **Model**: kimi-coding/k2p5

### Config file / key location

_No response_

### Additional provider/model setup details

_No response_

### Logs, screenshots, and evidence

```shell

Impact and severity

No response

Additional information

No response

extent analysis

Fix Plan

To resolve the issue of binding matching failures in concurrent scenarios, we need to ensure that the resolveAgentRoute function correctly isolates state in concurrent scenarios and that there is no global cache/state being incorrectly shared. Here are the steps to fix the issue:

  • Step 1: Review resolveAgentRoute function
    • Check if the function uses any global variables or shared state that could be accessed by multiple concurrent requests.
    • Ensure that the function creates a new scope for each request and does not rely on external state.
  • Step 2: Implement request-level caching
    • Instead of using a global cache, implement a request-level cache that stores the routing information for each request.
    • This can be achieved using a library like lodash.memoize or by creating a simple cache object that is specific to each request.
  • Step 3: Update resolveAgentRoute function to use request-level caching
    • Modify the resolveAgentRoute function to use the request-level cache instead of a global cache.
    • Ensure that the function correctly handles concurrent requests and does not overwrite the cache with incorrect information.

Example code snippet:

const _ = require('lodash');

// Create a request-level cache
const cache = {};

// Update resolveAgentRoute function to use request-level caching
function resolveAgentRoute(req) {
  const cacheKey = `agent-route-${req.peer.id}`;
  if (cache[cacheKey]) {
    return cache[cacheKey];
  }
  const agentRoute = // calculate agent route based on req
  cache[cacheKey] = agentRoute;
  return agentRoute;
}

Verification

To verify that the fix worked, you can test the concurrent scenario again and check if the messages are being routed correctly to their respective agents. You can also add logging statements to the resolveAgentRoute function to verify that the cache is being correctly updated and used.

Extra Tips

  • Ensure that the resolveAgentRoute function is correctly handling errors and edge cases.
  • Consider implementing a timeout or expiration mechanism for the request-level cache to prevent stale data from being stored.
  • Review the overall architecture of the system to ensure that there are no other potential issues with concurrent access to shared state.

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