{{ message }}
Repository navigation
fix(wechatcom): read a locally generated image instead of fetching it - #3312
Merged
zhayujie merged 1 commit intoSep 29, 2026
Merged
Conversation
An IMAGE_URL reply is how the agent hands over an image it wrote on disk (bridge/agent_bridge.py, channel/chat_channel.py), but this branch only knew how to fetch a URL, so requests raised "No connection adapters were found" and the picture disappeared with one error line beside the text the user kept receiving.
Owner
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.
Fixes #3311
An image the agent generates itself is handed to the channel as a local path —
bridge/agent_bridge.py:1902-1908returnsReply(ReplyType.IMAGE_URL, "file://<path>"), andchannel/chat_channel.py:417-422does the same for a media item it found on disk. The 企业微信应用 branch only knew how to fetch anIMAGE_URL, sodownload_bytesraisedInvalidSchema: No connection adapters were found for 'file://…', its ownexcept Exceptionlogged one line, and the picture vanished while the caption text stayed.What changed
channel/wechatcom/wechatcomapp_channel.py— theIMAGE_URLbranch now resolves the value the way thewechatmpsibling already does (channel/wechatmp/wechatmp_channel.py:190-195): strip afile://prefix, read the file when the path exists, otherwise keep using the bounded downloader. The network path, the size guard, the compression and the webp conversion are untouched.tests/test_wechatcom_file_reply.py— extends the fixture that file/video replies already use instead of adding a new harness:_Recorder.uploadnow accepts theBytesIOan image upload passes (file replies hand it a(name, body)tuple), recordssend_image, and three cases are added:file://image is uploaded and delivered;https://image is still downloaded before uploading, so the network path is pinned too.A missing local file is not swallowed by the new branch: it falls through to the existing download error log, which keeps this change to the one case it needs to fix.
How it was verified
37879dd3with no channel lifecycle:send(Reply(ReplyType.IMAGE_URL, "file://" + png))records an empty call list. With the fix the stub records("upload", "image", …, b"\x89png-body")followed by("image", "media-1").pytest tests/test_wechatcom_file_reply.py—2 failed, 8 passedbefore the change,10 passedafter.pytest tests/ -q): pristine master32 failed, 2277 passed; this branch32 failed, 2280 passed. TheFAILEDlines are byte-for-byte the same set of 32, so nothing regressed — those 32 are pre-existing environment-dependent failures on Windows, not caused by this diff.ruff check channel/wechatcom/wechatcomapp_channel.py tests/test_wechatcom_file_reply.py --select F --ignore F403,F405— clean.