Skip to content

fix(aiCore): remove openai-compatible providers from PDF native support list#13809

Merged
kangfenmao merged 11 commits intomainfrom
DeJeune/fix-file-part-type
Mar 26, 2026
Merged

fix(aiCore): remove openai-compatible providers from PDF native support list#13809
kangfenmao merged 11 commits intomainfrom
DeJeune/fix-file-part-type

Conversation

@DeJeune
Copy link
Copy Markdown
Collaborator

@DeJeune DeJeune commented Mar 26, 2026

What this PR does

Before this PR:

  • PDF_NATIVE_PROVIDER_TYPES included 'openai', 'new-api', and 'gateway' types, assuming all OpenAI-compatible providers support native PDF file input via the file part type.
  • Sending a PDF to providers like Moonshot/Kimi (which have type: 'openai') resulted in a 400 error: "invalid part type: file".
  • A special-case isCherryAI check was needed because CherryAI also has type: 'openai' but doesn't support native PDF.

After this PR:

  • Only first-party provider protocols (openai-response, anthropic, gemini, azure-openai, vertexai, aws-bedrock, vertex-anthropic) are in PDF_NATIVE_PROVIDER_TYPES.
  • All type: 'openai' providers (Moonshot, DeepSeek, Groq, CherryAI, cherryin, etc.) correctly have PDFs converted to text before sending.
  • The CherryAI special-case check is removed as it's no longer needed.

Why we need it and why it was done in this way

The following tradeoffs were made:

  • Removed 'openai' entirely from the native set rather than adding per-provider ID exceptions, because the actual OpenAI provider uses type: 'openai-response' (not 'openai'), and the vast majority of type: 'openai' providers are third-party APIs that don't support file parts.
  • Also removed '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 risk file part errors.

The following alternatives were considered:

  • Adding individual provider IDs (like moonshot) to a blocklist — rejected as it's whack-a-mole; new OpenAI-compatible providers would keep hitting the same bug.
  • Keeping 'openai' in the set and adding more ID-based exceptions — rejected for the same reason.

Links to places where the discussion took place:

Breaking 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

  • The actual OpenAI provider uses type: 'openai-response', which remains in the native set — real OpenAI API users are unaffected.
  • All existing tests updated to match new behavior. Test suite passes fully (3811 tests).
  • The isCherryAI special 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

Release note

Fixed PDF file upload failing with "invalid part type: file" error for OpenAI-compatible providers (Moonshot, DeepSeek, Groq, etc.). PDFs are now correctly converted to text for these providers.

DeJeune and others added 3 commits March 26, 2026 13:35
…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]>
Copy link
Copy Markdown
Collaborator

@EurFelux EurFelux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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额外处理下。

DeJeune and others added 5 commits March 26, 2026 15:35
…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]>
@DeJeune DeJeune requested a review from EurFelux March 26, 2026 07:52
DeJeune and others added 2 commits March 26, 2026 16:05
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]>
@kangfenmao kangfenmao merged commit 1d5bdfb into main Mar 26, 2026
7 checks passed
@kangfenmao kangfenmao deleted the DeJeune/fix-file-part-type branch March 26, 2026 09:09
@EurFelux EurFelux linked an issue Mar 26, 2026 that may be closed by this pull request
10 tasks
@kangfenmao kangfenmao mentioned this pull request Mar 26, 2026
10 tasks
kangfenmao added a commit that referenced this pull request Mar 26, 2026
<!-- 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: PDF documents not supported as attachments

3 participants