Repository navigation
fix(dingtalk): route text-only richText to the agent instead of dropping it - #3293
Merged
zhayujie merged 1 commit intoSep 29, 2026
Merged
Conversation
…ing it A richText message whose image list is empty is pure formatted text, but it was classified as ContextType.IMAGE with a "[未找到图片]" placeholder and no image_path. Both receive paths cache only when image_path is set and then return unconditionally, so the user's message produced no reply at all.
Owner
|
Merged, thanks! Text-only richText now reaches the agent the same way the with-images branch does, and the regression tests pin the cases that must not change. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
A DingTalk
richTextmessage whose image list is empty is pure formatted text,but
DingTalkMessageclassified it asContextType.IMAGEwith the[未找到图片]placeholder and never setimage_path. Both receive paths indingtalk_channel.py(single chat:689-694, group chat:767-772) cache anIMAGE message only when
image_pathexists and thenreturnunconditionally,so
produce()was never reached: the user's message got no reply at all, andnothing was logged above
debug.The fix extracts the text on that path, mirroring what the with-images branch
already does a few lines above, and only keeps the IMAGE placeholder when the
message genuinely carries neither an image nor text.
picturemessages with anempty image list are unchanged.
Fixes #3292.
Type of change
Checklist
Local verification, on
master@5da52c87:tests/test_dingtalk_richtext_without_images.pyon the unpatched file:1 failed, 2 passed— the failure is exactly the text-only richText casecoming back as
ContextType.IMAGE.3 passed. The two other cases pin the behaviour that must notchange (no image and no text keeps the placeholder;
picturewith an emptyimage list stays an IMAGE).
46 passed, withdingtalk_streamboth importable and absent, and in both collection orders.
ruff check --select Fon the two changed files:All checks passed!pytest tests/ -q:36 failed, 2228 passedon this branch vs36 failed, 2225 passedon a separate worktree at the same commit — samepre-existing failures, +3 = the new tests, so no regression.
links (
dingtalk_message.py:155-158and the unconditionalreturnindingtalk_channel.py) are verified by reading those paths, and the parsingfix itself is covered by the regression test above.