fix(core): extend DashScope provider detection with additional hostname rules - #4157
Merged
Conversation
…me rules Add internal domain patterns (*.dw.alibaba-inc.com and *.data.aliyun-inc.com) to isDashScopeProvider() so that DashScope-compatible private gateways are recognized without requiring DASHSCOPE_PROXY_BASE_URL. Closes #4138
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. |
…t-in Allow modelProviders entries to declare providerType: 'dashscope' so that custom endpoints on private gateways are recognized as DashScope-compatible without relying solely on hostname detection. Closes #4138
…inc.com / *.aliyun-inc.com Drop the business-specific dw./data. subdomain checks and treat any *.alibaba-inc.com or *.aliyun-inc.com host as DashScope-compatible. If a future internal service under these domains is not compatible, narrow it via a runtime provider property rather than re-introducing business-name subdomains.
Contributor
There was a problem hiding this comment.
Pull request overview
Expands DashScopeOpenAICompatibleProvider.isDashScopeProvider() so private gateways under internal Alibaba corporate domains are recognized as DashScope-compatible without requiring DASHSCOPE_PROXY_BASE_URL. The new matcher covers any subdomain of alibaba-inc.com or aliyun-inc.com (broader than what the PR description implies), and is also included in the proxy-mismatch warning path so the warning is suppressed for internal origins.
Changes:
- Add an
isInternalOrigincheck matching*.alibaba-inc.comand*.aliyun-inc.comhostnames. - Skip the "proxy configured but baseUrl does not match" debug warning when the URL is an internal origin, and include it in the final return.
- Add 5 unit tests covering subdomain matches and bare-domain rejections.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| packages/core/src/core/openaiContentGenerator/provider/dashscope.ts | Adds broad internal-domain matching to DashScope provider detection. |
| packages/core/src/core/openaiContentGenerator/provider/dashscope.test.ts | Adds positive subdomain and negative bare-domain test cases. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
wenshao
reviewed
May 16, 2026
wenshao
requested changes
May 16, 2026
wenshao
left a comment
wenshao
left a comment
Collaborator
There was a problem hiding this comment.
[Critical — Design Concern] The new isInternalOrigin wildcard path triggers all DashScope-specific request transformations unconditionally for ANY *.alibaba-inc.com / *.aliyun-inc.com service. Once isDashScopeProvider() returns true: buildHeaders() injects X-DashScope-CacheControl, X-DashScope-UserAgent, X-DashScope-AuthType headers; buildRequest() injects cache_control: { type: 'ephemeral' } into message content, vl_high_resolution_images for vision models, and DashScope-specific metadata (sessionId, promptId, channel). None of these transformations are gated on origin type — they apply identically whether the endpoint is dashscope.aliyuncs.com, an internal proxy, or a non-DashScope service that happens to be under *.alibaba-inc.com. A non-DashScope internal service under this domain would receive malformed requests with no indication anything is wrong — this is a 3 AM debugging nightmare. Consider whether internal services should skip the most invasive transformations (at minimum cache_control injection into messages and vl_high_resolution_images, which are strictly DashScope-specific).
— DeepSeek/deepseek-v4-pro via Qwen Code /review
wenshao
requested changes
May 17, 2026
wenshao
reviewed
May 17, 2026
wenshao
left a comment
wenshao
left a comment
Collaborator
There was a problem hiding this comment.
4 Suggestion-level findings from this review. The 3 existing Critical findings from prior reviews (wildcard too broad, description mismatch, zero observability) remain unaddressed.
Additional concern (not mappable to a diff line): buildRequest() now injects cache_control: { type: 'ephemeral' } into system messages and tool definitions for internal domains — previously these went through DefaultOpenAICompatibleProvider.buildRequest() with no cache control. An internal non-DashScope endpoint receiving these annotations could reject the request. Consider adding a test that constructs a DashScopeOpenAICompatibleProvider with an internal-domain baseUrl and asserts buildRequest() output.
— mimo-v2.5-pro via Qwen Code /review
wenshao
reviewed
May 17, 2026
wenshao
reviewed
May 17, 2026
wenshao
reviewed
May 17, 2026
wenshao
approved these changes
May 17, 2026
wenshao
left a comment
wenshao
left a comment
Collaborator
There was a problem hiding this comment.
No issues found. LGTM! ✅ — DeepSeek/deepseek-v4-pro via Qwen Code /review
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
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
Add generic internal Alibaba corporate-domain matching to
isDashScopeProvider()so private DashScope-compatible gateways can use DashScope provider behavior without requiringDASHSCOPE_PROXY_BASE_URL.Why
Private gateways that proxy to DashScope-compatible APIs may use internal corporate domains that do not match the built-in
dashscope.aliyuncs.com/dashscope-intl.aliyuncs.compatterns. Before this change, these endpoints fell through toDefaultOpenAICompatibleProvider, missing DashScope-specific headers, cache control, and metadata.What changed
dashscope.ts: Recognizes generic internal corporate-domain subdomains without hardcoding individual private gateway hostnames.dashscope.test.ts: Covers internal subdomains, multi-level and port-bearing URLs, bare-domain rejection, lookalike/suffix-spoofing negative cases, and proxy interaction.Test plan
cd packages/core && npx vitest run src/core/openaiContentGenerator/provider/dashscope.test.tsnpx prettier --check packages/core/src/core/openaiContentGenerator/provider/dashscope.ts packages/core/src/core/openaiContentGenerator/provider/dashscope.test.tsgit diff --checknpm run lintnpm run typechecknpm run buildCloses #4138