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

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.

Start by reproducing the Feishu group event and tracing the runtime path after the feishu-inbound Message received log, comparing it with the p2p path. Use ~/.mavis/logs/daemon-*.log and POST /mavis/channel-route/resolve as references; done means group messages reach route resolution, emit Message routed, and enter the expected session queue.