Conversation
…2402) Feishu CreateMessage only accepts receive_id_type of open_id/user_id/union_id/email/chat_id. The adapter's no-reply-anchor branch sent receive_id_type="thread_id", which the API rejects with [99992402] field validation failed — silently dropping media/file attachments in topic groups (and stale-thread auto-resume sends). Two changes that fix the whole class, not just .md files: - gateway/platforms/base.py: _thread_metadata_for_source now carries a reply_to_message_id anchor for Feishu threads, so media/file sends (which otherwise reach the adapter with no reply target) can use the supported ReplyMessage + reply_in_thread path and land inside the topic. Telegram/other-platform metadata is untouched. - plugins/platforms/feishu/adapter.py: when no reply anchor is available, _send_raw_message degrades to chat_id delivery instead of emitting the invalid thread_id receive_id_type, so the message still reaches the conversation rather than being dropped. Relates to #39526, #35576.
- Replace the change-detector assertion that froze the buggy receive_id_type="thread_id" behavior with invariants: no-anchor sends degrade to chat_id, and anchored sends use ReplyMessage with reply_in_thread=True so media lands in the topic. - Add base.py regression tests that Feishu thread metadata carries a reply_to_message_id anchor (and falls back to the source message id) without leaking telegram-only keys. Relates to #39526.
teknium1
left a comment
teknium1
left a comment
There was a problem hiding this comment.
Thanks for preserving the original investigation and removing the invalid receive_id_type="thread_id" branch. The bug remains present on current origin/main at plugins/platforms/feishu/adapter.py:4800, but this replacement still needs two routing fixes.
Problems
- The new fallback creates against
chat_idwhen a topic has no anchor. That avoids99992402, but can deliver topic-scoped media into the parent chat rather than the triggering topic. The linked maintainer review on #55067 identified this same failure mode. - The patch does not update GatewayRunner's separate metadata builder. Post-stream media obtains metadata at
gateway/run.py:18451;GatewayRunner._thread_metadata_for_target()returns onlythread_idatgateway/run.py:19748-19769, and the attachment sends retain that metadata atgateway/run.py:18477-18502. Those sends still lack the Feishu reply anchor added to the base helper.
Suggested changes
- Fail closed for a topic send with no valid reply anchor instead of creating a parent-chat message.
- Propagate Feishu
reply_to_message_idthrough the GatewayRunner post-stream path and cover it with an end-to-end routing test.
Automated hermes-sweeper review.
| # failed (observed for media/file sends in topic groups, and for stale | ||
| # thread anchors on auto-resume). Degrade to chat_id delivery so the | ||
| # message still reaches the conversation instead of being dropped. | ||
| receive_id = chat_id |
There was a problem hiding this comment.
For a topic send this fallback creates in the parent chat, so it can expose an attachment outside the triggering topic. Please fail the topic delivery when no valid reply anchor exists rather than degrading a threaded message to chat_id.
alt-glitch
added
type/bug
Duplicate of #55067: both implement the same Feishu reply-anchor propagation and replace invalid |
teknium1
added
the
sweeper:blast-moderate
|
Addressed both review findings in 4a82a0d: topic-scoped sends now fail closed when no reply anchor exists, and GatewayRunner post-stream media metadata now carries the triggering Feishu message anchor. Added focused regressions for both paths; 30 related tests pass locally. |
|
FlyingShuttle has changed its pre-v3.0.0 policy to consume official Hermes releases without carrying or proposing upstream patch work. Closing this project-driven PR; topic-thread attachment support remains a documented limitation until an official Hermes release addresses it. |
4 participants
What does this PR do?
Fixes outbound Feishu/Lark
MEDIA:attachments in topic groups. Text replies already useReplyMessage, but media/file sends reached the adapter without a reply anchor and fell through toCreateMessagewithreceive_id_type="thread_id". Feishu rejects that value with99992402, so users receive the text but not the attachment or its failure notice.This is an up-to-date replacement for #55067. Its two commits were cherry-picked so @qioer0762 remains the author; I resolved the conflicts against current
mainand re-ran the focused tests. The original PR is currently merge-conflicted and has no CI checks.Related Issue
Fixes #39526
Related: #55067, #35576
Type of Change
Changes Made
gateway/platforms/base.py: include the triggering Feishu message ID in thread metadata so native media usesReplyMessagewithreply_in_thread=True.plugins/platforms/feishu/adapter.py: never emit the unsupportedreceive_id_type="thread_id"; without an anchor, degrade to the valid chat target instead of silently dropping the message.How to Test
In a Feishu/Lark topic group, send a user message that makes the assistant return a valid
MEDIA:/absolute/path/report.txtdirective.Verify the text and native file attachment both appear inside the same topic.
Run:
Focused result on current
main: 27 passed, 0 failed.Checklist
Code
Documentation & Housekeeping
cli-config.yaml.example: N/A; no config change.CONTRIBUTING.md/AGENTS.md: N/A; no architecture or workflow change.Screenshots / Logs
The live reproduction is content-neutral: text was delivered in the correct Lark topic, while the requested
.txtattachment was absent. A source-level harness also confirmed that current code selectsCreateMessagefor media with thread-only metadata andReplyMessageonce the message anchor is present.