fix(core): match DeepSeek provider by model name for sglang/vllm (#3613)#3620
Merged
Conversation
Contributor
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
wenshao
commented
Apr 26, 2026
Collaborator
Author
|
No issues found. LGTM! ✅ — gpt-5.5 via Qwen Code /review |
Some OpenAI-compatible servers (notably sglang's deepseek-v4 jinja template) crash on the array form of message content even when it carries a single text block, with `TypeError: sequence item 0: expected str instance, list found` at `encoding_dsv4.py:336`. The DeepSeekOpenAICompatibleProvider already flattens content arrays into joined strings in buildRequest, but isDeepSeekProvider only matched on the official api.deepseek.com baseUrl. DeepSeek models served behind sglang / vllm / ollama / etc. bypass the workaround and hit the bug. Extend the matcher to also detect by model name (case-insensitive substring 'deepseek'), so any OpenAI-compatible endpoint serving a DeepSeek model picks up the same content-format flattening. Fixes #3613
9555eb6 to
91a7964
Compare
Collaborator
Author
|
按照 review 反馈调整了方向：放弃修改通用 converter，改为扩展 改动现在只动两个文件：
PR 标题和描述已可以直接 review 新方案。force-push 已完成。 |
| contentGeneratorConfig: ContentGeneratorConfig, | ||
| ): boolean { | ||
| const baseUrl = contentGeneratorConfig.baseUrl ?? ''; | ||
| if (baseUrl.toLowerCase().includes('api.deepseek.com')) { |
…ge-string-content
Collaborator
Author
|
tanzhenxin
approved these changes
Apr 26, 2026
xaelistic
pushed a commit
to xaelistic/qwen-code
that referenced
this pull request
Jun 7, 2026
xaelistic
pushed a commit
to xaelistic/qwen-code
that referenced
this pull request
Jun 7, 2026
…nLM#3613) (QwenLM#3620) Some OpenAI-compatible servers (notably sglang's deepseek-v4 jinja template) crash on the array form of message content even when it carries a single text block, with `TypeError: sequence item 0: expected str instance, list found` at `encoding_dsv4.py:336`. The DeepSeekOpenAICompatibleProvider already flattens content arrays into joined strings in buildRequest, but isDeepSeekProvider only matched on the official api.deepseek.com baseUrl. DeepSeek models served behind sglang / vllm / ollama / etc. bypass the workaround and hit the bug. Extend the matcher to also detect by model name (case-insensitive substring 'deepseek'), so any OpenAI-compatible endpoint serving a DeepSeek model picks up the same content-format flattening. Fixes QwenLM#3613 Co-authored-by: wenshao <wenshao@U-K7F6PQY3-2157.local>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Some OpenAI-compatible servers (notably sglang's deepseek-v4 jinja template) crash on the array form of message content even when it carries a single text block — see #3613, with
TypeError: sequence item 0: expected str instance, list foundatencoding_dsv4.py:336.DeepSeekOpenAICompatibleProvider.buildRequestalready flattens content arrays into joined strings, butisDeepSeekProvideronly matched on the officialapi.deepseek.combaseUrl. DeepSeek models served behind sglang / vllm / ollama / etc. bypass the workaround and hit the bug.Extend the matcher to also detect by model name (case-insensitive substring
deepseek), so any OpenAI-compatible endpoint serving a DeepSeek model picks up the existing flattening.Fixes #3613
Changes
provider/deepseek.ts:21-35:isDeepSeekProvidernow returns true if either baseUrl includesapi.deepseek.comOR model name containsdeepseek.provider/deepseek.test.ts: 1 existing case adjusted (so the spread default modeldeepseek-chatdoesn't accidentally satisfy the new rule when verifying baseUrl-negative); 2 new cases for the sglang scenario and case-insensitive matching.Test plan
provider/deepseek.test.ts: 9/9 passpackages/core: 6070/6072 pass (2 skipped, unrelated)tsc --noEmit: cleaneslint: clean--tool-call-parser deepseekv4server (issue reporter)