Uh oh!
There was an error while loading. Please reload this page.
fix: detect attachment mime from file contents - #29442
Conversation
The -f flag and @path references were hardcoding attachments as text/plain regardless of actual file type. Sniff magic bytes via the existing sniffAttachmentMime helper so image and PDF files get their real mime type and are routed correctly downstream.
This PR doesn't fully meet our contributing guidelines and PR template. What needs to be fixed:
Please edit this PR description to address the above within 2 hours, or it will be automatically closed. If you believe this was flagged incorrectly, please let a maintainer know. |
761a7da to
5a53815CompareThe following comment was made by an LLM, it may be inaccurate: Based on my search, I found one potentially related PR: PR #25317: fix: detect file MIME type from extension for -f attachments This PR is related because it addresses the same issue area (detecting MIME types for file attachments via the The other related PRs focus on image/file support features but don't directly address the same MIME detection problem:
|
This pull request has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window. Feel free to open a new pull request that follows our guidelines. |
Files attached via the
-fflag and@pathreferences in the prompt are hardcoded asmime: text/plainregardless of actual type. When the file is an image or PDF this causes the attachment to be dropped from the user message inmessage-v2.ts(which filters outtext/plainfile parts before serialization), so vision-capable models never see the image.Use the existing
sniffAttachmentMimehelper fromutil/media.ts(already used bytool/read.ts) to detect the type from the first 16 bytes of the file. Falls back totext/plainfor unknown types, preserving previous behaviour for plain-text attachments.Fixes#25353, #24698.
Test
bun test— 3032 pass / 0 failbun run typecheck— cleanbun run test:httpapi— 149 / 0bun run lint— 0 new errorsVerified manually with a 64×64 PNG: pre-fix, default model replied "I cannot process images"; post-fix, model correctly identifies the image content.