[Bug]: Feishu bridge drops group messages silently — p2p works, groups don't

@bot

Version / 版本号

mavis CLI: 3.0.46

Platform / 平台

Windows

OS version / 系统版本

windows 11 (daemon runs inside MiniMax Code desktop app, PID 15076)

Issue area / 问题类型

MCP / OAuth / integration

Upload ID / 日志上传 ID

cannot

What happened? / 问题描述

Summary
飞书群聊里 @bot 消息收得到但不响应，p2p 私聊完全正常。bridge 接收到群消息后，没有调用路由决策就被静默 drop，日志里只看到 Message received 看不到 Message routed。

Steps to reproduce
1.
在飞书开放平台创建一个 bot app，配置 WebSocket 长连接（不配置 webhook callback）
2.
把 bot 加进一个群聊
3.
配置好 mavis 的 mavis im channel bind mavis（这一步 p2p 验证可正常工作）
4.
在群里发送 @bot 测试消息
5.
观察 ~/.mavis/logs/daemon-*.log
Expected
群消息被 bridge 收到后，应该查 route rules 和 channel-bindings
命中规则的，按规则路由到对应 session
不命中的，按 mavis im defaults 配置的默认策略路由
Actual
群消息被静默丢弃，bridge 收到后没有任何后续动作
p2p 私聊消息路由完全正常
Diagnostic evidence (from daemon log)
收到后的两行几乎一样，但后续路径完全不同：

text

复制

群消息 — 收到后沉默（BUG）

[09:20:32.029] sdk-ws-conn invoke called: eventType=im.message.receive_v1

[09:20:32.030] [feishu-inbound] Message received: messageId=om_x100b6c2b2b238ca4b11c7e10b098836

                                   chatId=oc_a713a75fb3949cb0a0ad5bfbd83b8d45

                                   chatType=group

                                   senderId=ou_63c09f79d954ed4907e031e7a7d7fcad

                                   hasMention=true hasAttachments=false

[09:20:35.411] GET /mavis/health ← 之后什么都没有
text

复制

p2p 消息 — 立即路由（正常）

[09:21:16.330] sdk-ws-conn invoke called: eventType=im.message.receive_v1

[09:21:16.330] [feishu-inbound] Message received: ... chatType=p2p ... hasMention=true

[09:21:16.336] Message routed: platform=feishu, agentId=mavis,

                      sessionId=mvs_553df55b7b164454aebadab1c1a615ad,

                      ruleId=null, chatId=oc_c835cf3337197afc69f803a9b45f013a

[09:21:16.349] GET /mavis/api/session/mvs_553df55b7b164454aebadab1c1a615ad/queue
Configuration attempted (all saved correctly, none worked)

Route rule (via mavis im route add)
yaml

复制
id: feishu-group-main

platform: feishu

match: { chatType: group, chatId: oc_a713a75fb3949cb0a0ad5bfbd83b8d45 }

target: { agentId: mavis, sessionStrategy: per-chat }

enabled: true

priority: 10

requireMention: true
2. Default route (via mavis im defaults set)
json

复制
{ "feishu": { "agentId": "mavis", "sessionStrategy": "per-chat" } }
3. Manual binding (directly in ~/.mavis/channel-bindings.yaml)
yaml

复制
bindings:

mavis:oc_a713a75fb3949cb0a0ad5bfbd83b8d45:ou_63c09f79d954ed4907e031e7a7d7fcad:

agentId: mavis

sessionId: mvs_553df55b7b164454aebadab1c1a615ad

strategy: root

pinned: false

Verification
mavis im route test --platform feishu --chat-type group --chat-id oc_a713a75... --mention → returns ROUTED, ruleId: feishu-group-main, blocked: false ✅
POST /mavis/channel-route/resolve with the same params → returns the same ROUTED result ✅
API says it routes → runtime bridge doesn't route ❌
Workaround tried
Restarted MiniMax Code desktop app (which manages the daemon). New Plugin runner started: platform=feishu at 09:20:14, then a fresh group message at 09:20:32 STILL didn't get routed. So it's not a config-cache issue.
mavis im route add / mavis im route update / mavis im defaults set / mavis restart — mavis restart is refused with "managed by MiniMax desktop app" so the only way to restart the daemon is to quit/reopen the MiniMax Code app.
Hypothesis
The runtime feishu bridge has two separate message-handling paths:

p2p path: consults channel-bindings.yaml and/or default route, then logs Message routed
group path: receives the event but exits early before route resolution — neither rule engine nor binding lookup is consulted
The fact that route test and /mavis/channel-route/resolve work for group messages confirms the route engine is fine; the issue is specifically in the bridge's group message handler skipping the route resolution step.

Impact
完全无法在飞书群里使用 mavis bot，p2p 正常工作。这是群消息的硬阻断，影响所有想把 mavis 部署到团队群/客户群的场景。

Additional context
App credentials configured: ~/.mavis/credentials/mavis/feishu.json (appId cli_aa94fc5366381bb4)
Bot identity verified after restart: botName=mimax code, botOpenId=ou_8b9af4953936eab6311ee5014ecc00cc
WebSocket connection stable; no reconnect storms
Daemon managed by MiniMax Code desktop app, mavis restart/stop/start all refused
Reproduction log file
~/.mavis/logs/daemon-YYYYMMDDHH.log — search for feishu-inbound Message received to see all received events, then check whether Message routed follows.

Steps to reproduce / 复现步骤

在飞书开放平台创建一个 bot app，配置 WebSocket 长连接（不配置 webhook callback）
2.
把 bot 加进一个群聊
3.
配置好 mavis 的 mavis im channel bind mavis（这一步 p2p 验证可正常工作）
4.
在群里发送 @bot 测试消息
5.
观察 ~/.mavis/logs/daemon-*.log

Expected behavior / 预期行为

完全无法在飞群消息被 bridge 收到后，应该查 route rules 和 channel-bindings
命中规则的，按规则路由到对应 session
不命中的，按 mavis im defaults 配置的默认策略路由书群里使用 mavis bot，p2p 正常工作。这是群消息的硬阻断，影响所有想把 mavis 部署到团队群/客户群的场景。

Actual behavior / 实际行为

群消息被静默丢弃，bridge 收到后没有任何后续动作
p2p 私聊消息路由完全正常

Logs or crash report / 日志或崩溃信息

收到后的两行几乎一样，但后续路径完全不同：

text

复制
# 群消息 — 收到后沉默（BUG）
[09:20:32.029] sdk-ws-conn invoke called: eventType=im.message.receive_v1
[09:20:32.030] [feishu-inbound] Message received: messageId=om_x100b6c2b2b238ca4b11c7e10b098836
                                       chatId=oc_a713a75fb3949cb0a0ad5bfbd83b8d45
                                       chatType=group
                                       senderId=ou_63c09f79d954ed4907e031e7a7d7fcad
                                       hasMention=true hasAttachments=false
[09:20:35.411] GET /mavis/health   ← 之后什么都没有
text

复制
# p2p 消息 — 立即路由（正常）
[09:21:16.330] sdk-ws-conn invoke called: eventType=im.message.receive_v1
[09:21:16.330] [feishu-inbound] Message received: ... chatType=p2p ... hasMention=true
[09:21:16.336] Message routed: platform=feishu, agentId=mavis,
                          sessionId=mvs_553df55b7b164454aebadab1c1a615ad,
                          ruleId=null, chatId=oc_c835cf3337197afc69f803a9b45f013a
[09:21:16.349] GET /mavis/api/session/mvs_553df55b7b164454aebadab1c1a615ad/queue

Screenshots / 截图

No response

Before submitting / 提交前确认

I have searched existing issues.
I am using the latest version available to me.
I have removed sensitive information from logs/screenshots.

Confirmed independently on macOS with mavis CLI 3.0.46 + MiniMax Code desktop 2026.06. Adding my findings.

Root cause (confirmed)

/Applications/MiniMax Code.app/Contents/Resources/resources/daemon/daemon.js line 95785:

if (event.chatType !== "p2p") {
  logger.debug(`Dropping non-p2p event (group/channel/thread not supported): ...`);
  return;
}

This sits at the top of inboundEventHandler.handleRawEvent and runs BEFORE route resolution, channel-bindings lookup, or session dispatch. Every chatType=group event is silently dropped at debug log level (default logLevel: info does not surface it).

Reproduction (my session, 2026-06-18)

mavis im channel bind business-burger --platform feishu --app-id cli_aa94fc...
mavis im route add for the group chat
mavis im route test --mention returns ROUTED
Send @bot 你好 in the group
daemon log shows Message received then silence (no Message routed)
23+ workarounds attempted (im route defaults, channel-bindings manual edit, mention policy, agent.md stub, restart daemon) → all fail because execution never reaches that path

Why this is a daemon bug, not config

The route engine, channel-bindings, and default route are correctly populated — mavis im route test and /mavis/channel-route/resolve return ROUTED. The failure happens earlier, inside the inbound handler itself.

Workaround attempts that failed (so others do not repeat)

lark-cli event +subscribe with --output-dir events/ — drops events on 1.0.54; 1.0.56 still loses some after 80s lag
lark_oapi 1.5.3 FeishuWSClient — WS connects but register_p2_im_message_receive_v1 callback not invoked reliably across reconnects
Restarting MiniMax Code (Cmd+Q + reopen) — daemon reloads but the 95785 drop code is still there

Related issues across the agent ecosystem (this is a known class)

For reference, similar requireMention / group-drop bugs exist in other major agent frameworks:

[Bug] Structured card action callback filtered by requireMention in group chats openclaw/openclaw#85450 — Card action filtered by requireMention in group chats (P1, PR #85481 in flight)
TypeError: Cannot read properties of undefined (reading 'trim') on Feishu group messages with empty content openclaw/openclaw#66657 — TypeError on Feishu group messages with empty content (P1, PR #77109 in flight)
Feishu gateway silently drops messages sent in thread/topic with @mention NousResearch/hermes-agent#31336 — Feishu thread/topic drop (PR #31359 in flight)

All three have working PRs in flight. This issue (#79) is currently the only one without any PR progress or maintainer engagement.

Suggested fix

In daemon.js around line 95785, change the early return to either:

Remove the chatType !== "p2p" gate entirely and let route resolution decide; OR
Run route resolution first, then drop only events that do not match any rule.

Either way, requireMention: true should be a route-level concern (which it already is via mavis im route add --require-mention), not an inbound-handler-level concern. The current placement silently swallows all group traffic before the route layer can decide.

Environment

mavis CLI 3.0.46
MiniMax Code desktop 2026.06 (verified 95785 exists in bundled daemon.js)
macOS, daemon managed by desktop app (cannot be restarted via mavis restart)
App credentials: ~/.mavis/credentials/<agent>/feishu.json
Bot identity verified: botName=千辰 BURGER, botOpenId=ou_e5ca9bcfda0c5041b787146386add54d
WebSocket connection stable; no reconnect storms

This was generated by AI during triage.

感谢非常有价值的日志线索（「Message received 后无 Message routed」把范围缩得很小）。

初步怀疑：群聊消息在进入路由决策前有一层过滤——群消息需要命中显式的 route rule 或群绑定，未命中时没有走 im defaults 的默认策略，而是被静默丢弃且不打日志。p2p 正常、群聊沉默的表现与此吻合。

为确认，请补充两个信息：

mavis im defaults 与 route rules 的当前配置输出（脱敏）；
飞书开放平台上 bot 是否开通了群聊消息接收权限（im:message.group_at_msg 及相关事件订阅）。

Closing as part of a backlog cleanup: this issue was filed more than a month ago against an older release, and the codebase has changed substantially since then. If it still reproduces on the latest version, please open a new issue with the current version and reproduction steps. Thank you for the report!

批量清理积压：该 issue 创建已超过一个月，针对的是较旧版本，代码已有较大变化。如果在最新版本上仍能复现，欢迎附上当前版本号和复现步骤重新提交 issue。感谢反馈！

Navigation Menu

Repository navigation

[Bug]: Feishu bridge drops group messages silently — p2p works, groups don't #79

Version / 版本号

Platform / 平台

OS version / 系统版本

Issue area / 问题类型

Upload ID / 日志上传 ID

What happened? / 问题描述

群消息 — 收到后沉默（BUG）

p2p 消息 — 立即路由（正常）

Steps to reproduce / 复现步骤

Expected behavior / 预期行为

Actual behavior / 实际行为

Logs or crash report / 日志或崩溃信息

Screenshots / 截图

Before submitting / 提交前确认

Root cause (confirmed)

Reproduction (my session, 2026-06-18)

Why this is a daemon bug, not config

Workaround attempts that failed (so others do not repeat)

Related issues across the agent ecosystem (this is a known class)

Suggested fix

Environment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Feishu bridge drops group messages silently — p2p works, groups don't #79

Description

Version / 版本号

Platform / 平台

OS version / 系统版本

Issue area / 问题类型

Upload ID / 日志上传 ID

What happened? / 问题描述

群消息 — 收到后沉默（BUG）

p2p 消息 — 立即路由（正常）

Steps to reproduce / 复现步骤

Expected behavior / 预期行为

Actual behavior / 实际行为

Logs or crash report / 日志或崩溃信息

Screenshots / 截图

Before submitting / 提交前确认

Activity

jelenneth commented on Jun 18, 2026

Root cause (confirmed)

Reproduction (my session, 2026-06-18)

Why this is a daemon bug, not config

Workaround attempts that failed (so others do not repeat)

Related issues across the agent ecosystem (this is a known class)

Suggested fix

Environment

hetaoBackend commented on Sep 21, 2026

hetaoBackend commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions