Repository navigation
media: relay an animated image document as an image - #9
Merged
std-microblock merged 1 commit intoOct 14, 2026
Merged
Conversation
A GIF sent from a Telegram client arrives as an uploaded document, so the relay classified it as a file and the platform relayed it as a plain attachment: on QQ the user saw a "<uuid>.gif" file card for a message they sent as an animation, and other Crossgram clients saw a file document too. The relay already models an animated image document as an image in the other direction, so send the same kind to the platform. Only a document that carries both the animated image mime and documentAttributeAnimated counts, which keeps an explicit "send as file" and a silent video on the file path.
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.
问题
从 Telegram 侧发一个 GIF(没有选 send as file),到 QQ 群里落地成「文件」卡片,名字是客户端上传时的
<uuid>.gif;其它 Crossgram 客户端看到的也是.giffile document。预期是 QQ 侧当动图/图片显示。方向已确认是 TG → QQ。
原因
TG → QQ 的媒体类型只在
DialogRpc._resolveUploadedMedia()里判一次:inputMediaUploadedPhoto→image;file,包括以文档形式上传的动图。这里既没有看 mime,也没有看documentAttributeAnimated,mimeType在下面几行才被读出来用于其它字段。于是 GIF 变成
kind: 'file',平台的媒体规格里也是file,最后按普通文件上传/转发。同一个仓库在反方向(QQ → TG)是认得动图的——投影时会把这个文档投影成kind: 'image'+image/gif(isAnimatedImageMime()),也就是说中继自己的模型里 GIF 就是图片,只有发送这一段没跟上。修复
packages/bridge/src/dialogs.ts:把「客户端标了documentAttributeAnimated且 mime 是image/gif/image/apng的上传文档」也判成image。两个条件都要,是为了不改变现有语义:
video/mp4)不会被当成图片,仍然走平台既有的视频/文件判断。验证
packages/bridge/src/media-send.test.ts新增 3 个用例:image/gif文档 → 平台收到kind: 'image';image/gif文档(send as file)→ 仍然是kind: 'file';video/mp4文档 → 仍然是kind: 'file'。唯一的失败是
voice/voice-worker-client.test.ts(spawn cargo ENOENT,本机没有 cargo),与本次改动无关。还需要确认的点
qqnt-bridge不在本工作区),所以这里没有加体积兜底。如果超大的动图在 QQ 图片通道会失败,需要按实际上限加一个退回文件的判断——我可以在拿到上限后补。crossgram.prepareMediaUploadV3的kind是客户端给的(Crossgram::FastUpload::Kind()只把 photo 判成image),只影响秒传命中的那条优化路径,需要改 desktop 补丁(另一个仓库),本 PR 不涉及。来源:Koishi On Topic 群的实测反馈(「tg 发 gif 到 qq 发出来的是文件,应该是图片才对」)。