| … | … | @@ -19,6 +19,17 @@ export const GENERIC_MIME_TYPES = new Set([ | |
| 27 | + | return ( | |
| 28 | + | mimeType === "image/svg+xml" || | |
| 29 | + | ((mimeType === "" || GENERIC_MIME_TYPES.has(mimeType)) && /\.svg$/i.test(attachment.name)) | |
| 30 | + | ); | |
🟡 Medium src/image.ts:27
isSvgAttachment returns true for an image/svg+xml file named without a .svg extension, so it takes the SVG thumbnail path while the server stores and serves the -bin attachment as a download; the <img> cannot render the preview. Require a .svg filename for this branch, or normalize the upload name so the server can serve it inline.
| 1 | return ( |
| 2 | /\.svg$/i.test(attachment.name) && |
| 3 | (mimeType === "image/svg+xml" || mimeType === "" || GENERIC_MIME_TYPES.has(mimeType)) |
| 4 | ); |
Also found in 1 other location(s)
apps/web/src/components/chat/composerAttachmentFiles.ts:66
isSvgAttachmentaccepts an SVG solely by MIME type even when the filename has no.svgextension (for example,new File(..., "diagram", { type: "image/svg+xml" })). This then takes the new file path, but uploads are named fromattachmentFileExtension(input.name), producing a-binattachment;issueAssetUrlonly enables inline previews for an attachment-idsvgextension and marks all other generic files for download. Consequently the chip's<img>receives an octet-stream download rather than an SVG, so valid MIME-typed SVGs attach but never get the promised composer/transcript thumbnail (and lose their SVG filename for the provider). Normalize such files to a.svgupload name/extension or make the server's inline decision account for the validated SVG MIME type.
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
| 1 | In file @packages/shared/src/image.ts around lines 27-30: |
| 2 | |
| 3 | `isSvgAttachment` returns `true` for an `image/svg+xml` file named without a `.svg` extension, so it takes the SVG thumbnail path while the server stores and serves the `-bin` attachment as a download; the `<img>` cannot render the preview. Require a `.svg` filename for this branch, or normalize the upload name so the server can serve it inline. |
| 4 | |
| 5 | Also found in 1 other location(s): |
| 6 | - apps/web/src/components/chat/composerAttachmentFiles.ts:66 -- `isSvgAttachment` accepts an SVG solely by MIME type even when the filename has no `.svg` extension (for example, `new File(..., "diagram", { type: "image/svg+xml" })`). This then takes the new file path, but uploads are named from `attachmentFileExtension(input.name)`, producing a `-bin` attachment; `issueAssetUrl` only enables inline previews for an attachment-id `svg` extension and marks all other generic files for download. Consequently the chip's `<img>` receives an octet-stream download rather than an SVG, so valid MIME-typed SVGs attach but never get the promised composer/transcript thumbnail (and lose their SVG filename for the provider). Normalize such files to a `.svg` upload name/extension or make the server's inline decision account for the validated SVG MIME type. |
Note
Written by gpt-6.1-sol on behalf of Maria
already addressed by 08e92197f2: AttachmentUpload.ts normalizes MIME-identified SVG names to .svg before creating the signed attachment id, and AttachmentClaims.ts keeps that filename. the existing upload/claim regression covers diagram and diagram.bin and passed in this turn's 64-test run.
