Skip to content

fix: replace unsupported 'file' content type with text fallback for PDF (#1832)#1838

Closed
echoVic wants to merge 1 commit intoQwenLM:mainfrom
echoVic:fix/pdf-file-type-unsupported
Closed

fix: replace unsupported 'file' content type with text fallback for PDF (#1832)#1838
echoVic wants to merge 1 commit intoQwenLM:mainfrom
echoVic:fix/pdf-file-type-unsupported

Conversation

@echoVic
Copy link
Copy Markdown
Contributor

@echoVic echoVic commented Feb 14, 2026

Problem

When read_file reads a PDF file, the OpenAI content converter generates content parts with type: 'file', but DashScope/Qwen API only supports text, image_url, video_url, and video content types. This causes a 400 error:

Error: Internal error (code: -32603)
Data: {"details":"400 Invalid value: file. Supported values are: 'text','image_url','video_url' and 'video'."}

Root Cause

In converter.ts, the createMediaContentPart method converts PDF inlineData and fileData parts to type: 'file' format (OpenAIContentPartFile), which is not supported by the DashScope API.

Fix

  • Replace PDF content parts with a descriptive text fallback instead of the unsupported type: 'file' format
  • Remove the unused OpenAIContentPartFile type definition
  • Update converter tests to match the new behavior

All 49 existing tests pass.

Fixes #1832

…DF (QwenLM#1832)

DashScope/Qwen API returns 400 error when receiving content parts with
type: 'file'. The API only supports 'text', 'image_url', 'video_url',
and 'video' content types.

When read_file reads a PDF, the converter was generating type: 'file'
parts which DashScope rejects. This change replaces PDF content parts
with a descriptive text fallback, preventing the 400 error.

- Remove OpenAIContentPartFile type (no longer used)
- Convert inlineData PDF parts to text description instead of file type
- Convert fileData PDF parts to text description instead of file type
- Update converter tests to match new behavior

Fixes QwenLM#1832
@tanzhenxin
Copy link
Copy Markdown
Collaborator

@echoVic Thank for your contribution! But we're going with #1982 because it solves the same problem more comprehensively: instead of blocking PDFs entirely, it assigns appropriate modalities per model. This means we can support it once a model can read PDFs natively.

Thanks again for taking the time to dig into this and write such a thorough PR!

@tanzhenxin tanzhenxin closed this Mar 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

2 participants