Environment
- Package:
lark-oapi 1.6.7 (Python)
- Python: 3.9+
- Affected path:
lark_oapi/channel/normalize/pipeline.py
Summary
InboundMessage.mentioned_bot is unconditionally False for all IM (text/post) messages, even when the bot is explicitly mentioned and the bot identity is fully resolved.
Root Cause
Two compounding omissions in lark_oapi/channel/normalize/pipeline.py:
1. bot_open_id not passed to extract_mentions (line 163)
# pipeline.py:163 — current (broken)
ext = extract_mentions(raw_mentions)
mentions.py:147 only sets ext.mentioned_bot = True when bot_open_id and parsed.open_id == bot_open_id. Since bot_open_id is never passed, ext.mentioned_bot stays False for every IM message.
2. mentioned_bot not forwarded to InboundMessage (lines 253-266)
Even if ext.mentioned_bot were computed, it is never passed to the InboundMessage(...) constructor — only mentions= and mentioned_all= are. The field falls back to its default False (types.py:387). pipeline.py contains no reference to mentioned_bot at all.
Evidence: SDK works around its own bug internally
policy_gate.py:142-143 re-computes the bot-mention check inline rather than trusting msg.mentioned_bot:
mentioned_bot = bool(
bot_open_id and any(m.open_id == bot_open_id for m in msg.mentions)
)
This confirms the maintainers know the field is unreliable; the internal gate self-heals, but the public-facing field exposed to on("message") consumers was never fixed.
Contrast with the comment path (correct)
comment.py:112 computes mentioned_bot_flag and :137 passes mentioned_bot=mentioned_bot_flag to the comment event. Only the IM path is broken.
Impact
Any consumer reading msg.mentioned_bot in an on("message") handler always receives False, causing "bot is @-mentioned in a group but does not respond" bugs. Verified empirically: with the bot present in mentions and bot_identity resolved, msg.mentioned_bot was still False.
Suggested Fix
In pipeline.py, obtain bot_open_id (same source as policy_gate), pass it to extract_mentions, and forward the result:
bot_open_id = getattr(self._cfg.app, "bot_open_id", None)
ext = extract_mentions(raw_mentions, bot_open_id=bot_open_id)
...
return InboundMessage(
...
mentions=mentions,
mentioned_all=mentioned_all,
mentioned_bot=ext.mentioned_bot, # ADD THIS
...
)
Environment
lark-oapi1.6.7 (Python)lark_oapi/channel/normalize/pipeline.pySummary
InboundMessage.mentioned_botis unconditionallyFalsefor all IM (text/post) messages, even when the bot is explicitly mentioned and the bot identity is fully resolved.Root Cause
Two compounding omissions in
lark_oapi/channel/normalize/pipeline.py:1.
bot_open_idnot passed toextract_mentions(line 163)mentions.py:147only setsext.mentioned_bot = Truewhenbot_open_id and parsed.open_id == bot_open_id. Sincebot_open_idis never passed,ext.mentioned_botstaysFalsefor every IM message.2.
mentioned_botnot forwarded toInboundMessage(lines 253-266)Even if
ext.mentioned_botwere computed, it is never passed to theInboundMessage(...)constructor — onlymentions=andmentioned_all=are. The field falls back to its defaultFalse(types.py:387).pipeline.pycontains no reference tomentioned_botat all.Evidence: SDK works around its own bug internally
policy_gate.py:142-143re-computes the bot-mention check inline rather than trustingmsg.mentioned_bot:This confirms the maintainers know the field is unreliable; the internal gate self-heals, but the public-facing field exposed to
on("message")consumers was never fixed.Contrast with the comment path (correct)
comment.py:112computesmentioned_bot_flagand:137passesmentioned_bot=mentioned_bot_flagto the comment event. Only the IM path is broken.Impact
Any consumer reading
msg.mentioned_botin anon("message")handler always receivesFalse, causing "bot is @-mentioned in a group but does not respond" bugs. Verified empirically: with the bot present inmentionsandbot_identityresolved,msg.mentioned_botwas stillFalse.Suggested Fix
In
pipeline.py, obtainbot_open_id(same source aspolicy_gate), pass it toextract_mentions, and forward the result: