fix(aiCore): remove openai-compatible providers from PDF native support list#13809
fix(aiCore): remove openai-compatible providers from PDF native support list#13809kangfenmao merged 11 commits intomainfrom
Conversation
…rt list OpenAI-compatible providers (type 'openai', 'new-api', 'gateway') were incorrectly included in PDF_NATIVE_PROVIDER_TYPES, causing PDF FileParts to be sent as-is to APIs like Moonshot/Kimi that don't support the 'file' part type. This resulted in 400 errors: "invalid part type: file". Only first-party provider protocols (openai-response, anthropic, gemini, azure-openai, vertexai, aws-bedrock, vertex-anthropic) now bypass the PDF-to-text conversion. All openai-compatible third-party providers will correctly have PDFs converted to text before sending. Also removes the now-unnecessary CherryAI special-case check since CherryAI uses type 'openai' which is no longer in the native set. Co-Authored-By: Claude Opus 4.6 <[email protected]> Signed-off-by: suyao <[email protected]>
…file support
OpenAI-compatible providers (type 'openai') like Moonshot/Kimi don't
support the 'file' part type, causing 400 errors when sending PDFs.
Remove 'openai' from PDF_NATIVE_PROVIDER_TYPES since most third-party
providers using this type don't support native PDF file input. Keep
aggregator types ('new-api', 'gateway') that forward to native backends.
Add PDF_NATIVE_AGGREGATOR_IDS allowlist for specific 'openai'-type
aggregators (cherryin) that do support native PDF.
Co-Authored-By: Claude Opus 4.6 <[email protected]>
Signed-off-by: suyao <[email protected]>
cherryin is a new-api aggregator, not a standalone openai-compatible provider. Remove the unnecessary PDF_NATIVE_AGGREGATOR_IDS set since new-api type is already in PDF_NATIVE_PROVIDER_TYPES. Co-Authored-By: Claude Opus 4.6 <[email protected]> Signed-off-by: suyao <[email protected]>
There was a problem hiding this comment.
Note
This review was translated by Claude.
The ideal approach would be to investigate the support status of each built-in provider, implement blacklist/whitelist handling, then make custom APIs unavailable by default, and provide a compatibility option to enable native PDF. The tricky part is with new-api-like services, where some models may support it while others don't. If we want to implement this, we'd need to add compatibility fields to the Model.
For now, we can prioritize compatibility. I'm not sure about the gateway, but new-api likely also has situations where file parts are not compatible, so we need to handle the model endpoint additionally.
Original Content
理想的方案是调查每个内置提供商的支持情况,做黑/白名单处理,然后自定义 api 的默认不可用,提供兼容选项启用原生 pdf。比较难办的是new-api这样的,可能部分模型支持,部分模型不支持。如果要做,还得把兼容字段做到 Model 上去才行。
目前可以先优先兼容性,gateway我不太清楚,但new-api很可能也有不兼容file part的情况,需要针对model endpoint额外处理下。
…F plugin For aggregator providers (new-api, gateway), check the model's endpoint_type to determine PDF native support instead of blanket allowing/denying. Only anthropic, gemini, and openai-response endpoints are treated as native PDF capable. Co-Authored-By: Claude Opus 4.6 <[email protected]> Signed-off-by: suyao <[email protected]>
…ints Non-OpenAI models may also use the openai-response endpoint but don't support the file part type. Only anthropic and gemini endpoints are treated as native PDF capable for aggregator providers. Co-Authored-By: Claude Opus 4.6 <[email protected]> Signed-off-by: suyao <[email protected]>
Non-Claude models may also use the anthropic endpoint but don't support the file part type. Only gemini endpoint is now treated as native PDF capable for aggregator providers. Co-Authored-By: Claude Opus 4.6 <[email protected]> Signed-off-by: suyao <[email protected]>
… models OpenAI and Claude models always support native PDF file input regardless of provider type. Check model identity first before falling back to provider type and endpoint_type checks. Co-Authored-By: Claude Opus 4.6 <[email protected]> Signed-off-by: suyao <[email protected]>
… plugin With model-level checks for OpenAI/Claude models taking priority, the aggregator endpoint_type logic is redundant. Simplify supportsNativePdf to only check model identity and provider type. Co-Authored-By: Claude Opus 4.6 <[email protected]> Signed-off-by: suyao <[email protected]>
Add isGeminiModel check alongside isOpenAIModel and isAnthropicModel so Gemini models also support native PDF on any provider type. Co-Authored-By: Claude Opus 4.6 <[email protected]> Signed-off-by: suyao <[email protected]>
Restrict OpenAI model detection to LLM models only, excluding image generation and other non-LLM OpenAI models that don't support native PDF file input. Co-Authored-By: Claude Opus 4.6 <[email protected]> Signed-off-by: suyao <[email protected]>
<!-- Template from https://github.com/kubevirt/kubevirt/blob/main/.github/PULL_REQUEST_TEMPLATE.md?--> <!-- Thanks for sending a pull request! Here are some tips for you: 1. Consider creating this PR as draft: https://github.com/CherryHQ/cherry-studio/blob/main/CONTRIBUTING.md --> <!--⚠️ Important: Redux/IndexedDB Data-Changing Feature PRs Temporarily On Hold⚠️ Please note: For our current development cycle, we are not accepting feature Pull Requests that introduce changes to Redux data models or IndexedDB schemas. While we value your contributions, PRs of this nature will be blocked without merge. We welcome all other contributions (bug fixes, perf enhancements, docs, etc.). Thank you! Once version 2.0.0 is released, we will resume reviewing feature PRs. --> ### What this PR does Before this PR: - Version was at 1.8.3 After this PR: - Bumps version to 1.8.4 - Updates release notes with bilingual (English/Chinese) content ### Release Notes Cherry Studio 1.8.4 - Bug Fixes and New Features **English:** - [API] Add knowledge base REST API endpoints - [SelectionAssistant] Add Linux support for text selection toolbar - [Files] Fix PDF upload failing with "invalid part type: file" error for OpenAI-compatible providers (Moonshot, DeepSeek, Groq, etc.) **Chinese:** - [API] 添加知识库 REST API 端点 - [选择助手] 为文本选择工具栏添加 Linux 支持 - [文件] 修复 OpenAI 兼容提供商(Moonshot、DeepSeek、Groq 等)的 PDF 上传失败问题("invalid part type: file" 错误) ### Included Commits 1. fix(aiCore): remove openai-compatible providers from PDF native support list (#13809) 2. feat(api): add knowledge base REST API endpoints (#13762) 3. feat(SelectionAssistant): Linux support (#13720) 4. fix(aiCore): add missing @openrouter/ai-sdk-provider dependency (#13787) (Skipped internal CI/CD changes) ### Review Checklist - [ ] Review generated release notes in `electron-builder.yml` - [ ] Verify version bump in `package.json` - [ ] CI passes - [ ] Merge to trigger release build ### Checklist This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR. Approvers are expected to review this list. - [x] PR: The PR description is expressive enough and will help future contributors - [x] Code: [Write code that humans can understand](https://en.wikiquote.org/wiki/Martin_Fowler#code-for-humans) and [Keep it simple](https://en.wikipedia.org/wiki/KISS_principle) - [x] Refactor: You have [left the code cleaner than you found it (Boy Scout Rule)](https://learning.oreilly.com/library/view/97-things-every/9780596809515/ch08.html) - [x] Upgrade: Impact of this change on upgrade flows was considered and addressed if required - [x] Documentation: A [user-guide update](https://docs.cherry-ai.com) was considered and is present (link) or not required. Check this only when the PR introduces or changes a user-facing feature or behavior. - [x] Self-review: I have reviewed my own code (e.g., via [`/gh-pr-review`](/.claude/skills/gh-pr-review/SKILL.md), `gh pr diff`, or GitHub UI) before requesting review from others ### Release note ```release-note Cherry Studio 1.8.4 - Bug Fixes and New Features ✨ New Features - [API] Add knowledge base REST API endpoints - [SelectionAssistant] Add Linux support for text selection toolbar 🐛 Bug Fixes - [Files] Fix PDF upload failing with "invalid part type: file" error for OpenAI-compatible providers (Moonshot, DeepSeek, Groq, etc.) ``` Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
What this PR does
Before this PR:
PDF_NATIVE_PROVIDER_TYPESincluded'openai','new-api', and'gateway'types, assuming all OpenAI-compatible providers support native PDF file input via thefilepart type.type: 'openai') resulted in a 400 error:"invalid part type: file".isCherryAIcheck was needed because CherryAI also hastype: 'openai'but doesn't support native PDF.After this PR:
openai-response,anthropic,gemini,azure-openai,vertexai,aws-bedrock,vertex-anthropic) are inPDF_NATIVE_PROVIDER_TYPES.type: 'openai'providers (Moonshot, DeepSeek, Groq, CherryAI, cherryin, etc.) correctly have PDFs converted to text before sending.Why we need it and why it was done in this way
The following tradeoffs were made:
'openai'entirely from the native set rather than adding per-provider ID exceptions, because the actual OpenAI provider usestype: 'openai-response'(not'openai'), and the vast majority oftype: 'openai'providers are third-party APIs that don't supportfileparts.'new-api'and'gateway'aggregator types, since these route to various backends — it's safer to convert PDFs to text and let specific backends handle text rather than riskfilepart errors.The following alternatives were considered:
moonshot) to a blocklist — rejected as it's whack-a-mole; new OpenAI-compatible providers would keep hitting the same bug.'openai'in the set and adding more ID-based exceptions — rejected for the same reason.Links to places where the discussion took place:
pdfCompatibilityPluginwith the overly broad provider type setBreaking changes
None. Providers that previously had PDFs silently fail with 400 errors will now correctly receive extracted text content instead.
Special notes for your reviewer
type: 'openai-response', which remains in the native set — real OpenAI API users are unaffected.isCherryAIspecial case from PR fix: prevent CherryAI provider from using native PDF input in middleware #13777 is removed since CherryAI (type: 'openai') is now naturally handled by the conversion path.Checklist
/gh-pr-review,gh pr diff, or GitHub UI) before requesting review from othersRelease note