openclaw - 💡(How to fix) Fix [Bug] dingtalk-connector: Pasted images map to wrong file:// URL in media/inbound [1 comments, 2 participants]

Bug Description When a user pastes an image directly into a DingTalk chat, the file:// URL generated in the message does not correctly map to the actual image file stored in media/inbound. This causes the AI to read a different image than the one the user uploaded. Steps to Reproduce User pastes Image A into DingTalk chat → message contains file://...openclaw-media-XXX-A.png User pastes Image B into DingTalk chat → message contains file://...openclaw-media-YYY-B.png AI reads Image B's message but actually retrieves Image A (or another wrong image) from media/inbound Key observation: The openclaw-media-XXX filename in the message does NOT match the actual file that was uploaded for that message. Expected Behavior The file:// URL in the message should correctly reference the image file that was actually uploaded and stored in media/inbound for that specific message. Actual Behavior The file:// URL in the message references a mismatched file in media/inbound, causing the AI to read the wrong image. Environment Platform: DingTalk Channel: dingtalk-connector OpenClaw version: latest Image input method: paste (Ctrl+V / right-click paste) Root Cause (Suspected) The connector appears to have a bug in how it generates and maps filenames when processing directly-pasted images: User pastes image → connector uploads to media/inbound Connector generates a new filename and stores the file Connector creates message with file:// URL Bug: The file:// URL does not correctly reference the newly stored file — it may reference an old/stale path or have incorrect mapping logic Suggested Investigation Compare message file:// URL filenames against actual media/inbound filenames created at the same timestamp Check connector's filename generation and mapping logic for pasted images Verify whet