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

[xuess1]

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)

1. 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.

[jelenneth]

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)

1. lark-cli event +subscribe with --output-dir events/ — drops events on 1.0.54; 1.0.56 still loses some after 80s lag
2. lark_oapi 1.5.3 FeishuWSClient — WS connects but register_p2_im_message_receive_v1 callback not invoked reliably across reconnects
3. 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:

1. Remove the chatType !== "p2p" gate entirely and let route resolution decide; OR
2. 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