feat(core): inject request metadata for alicloudapi.com gateways - #9103
Merged
Conversation
Treat *.alicloudapi.com (Alibaba Cloud API Gateway) as a DashScope-compatible origin so request bodies carry the session tracking metadata (sessionId, promptId, channel), matching the existing handling for internal Alibaba domains. Fixes #9101
yiliang114
requested review from
LaZzyMan,
doudouOUC,
tanzhenxin and
wenshao
as code owners
August 13, 2026 14:06
github-actions
Bot
added
the
review/self-reported
Collaborator
Add an end-to-end determineProvider + buildRequest regression proving the acceptance criteria (metadata in the request body), and assert the alicloudapi origin activation debug log for parity with internal origins.
Collaborator
Author
Verification report (post-review)
Review fixes
Verification pack
Acceptance-criteria proof (unit level)With
Boundary cases covered
Not validated / out of scope
|
Collaborator
|
Thanks for the PR! Template looks good ✓ Problem: an observed functional gap, not a theoretical one — linked issue #9101 (triaged as Direction: aligned, and on a well-traveled path — the CHANGELOG has several prior extensions of DashScope provider detection (#4157 hostname rules, #2060 subdomain patterns, #3991 gateway support via Size: core path ( Approach: minimal and pattern-conforming — one dot-anchored hostname suffix check mirroring the existing Risk: Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题：已观测到的功能缺口，不是理论问题——关联 issue #9101（已分级为 方向：对齐，且这条路径已有充分先例——CHANGELOG 中有多次 DashScope provider 检测的扩展（#4157 主机名规则、#2060 子域名模式、#3991 通过 规模：核心路径（ 方案：最小且符合既有模式——按现有 风险： 进入代码审查 🔍 — Qwen Code · qwen3.8-max Reviewed at |
Collaborator
Code reviewMy independent proposal for this issue, written before reading the diff: add a dot-anchored Verified against the code:
No blockers. Three non-blocking observations:
Test evidence (the PR's own CI, read via the API — PR code is never executed in this review)At review time the head has no failed checks; the ubuntu unit suite was still running. Final CI results for
One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。 What the suite pins: the five detection assertions (subdomain ✓, port-bearing ✓, bare domain ✗, 中文说明代码审查在读 diff 之前，我对这个 issue 的独立方案是：在 对照代码核实：
无阻塞问题。三点非阻塞观察：
测试证据（来自该 PR 自身 CI，经 API 读取——审查过程从不执行 PR 代码）审查时该 head 上无失败检查；ubuntu 单测套件仍在运行。 套件钉住的内容：5 条检测断言（子域名 ✓、带端口 ✓、裸域名 ✗、 — Qwen Code · qwen3.8-max Reviewed at |
Collaborator
|
Confidence: 4/5 — clean, minimal change that matches my independent proposal exactly, with a suite that pins the acceptance path end-to-end; the remaining notes are non-blocking. Stepping back: the approach is exactly what I would have written — one dot-anchored suffix check in the established origin pattern plus the negative cases, and a follow-up commit adding the parallel debug log and an end-to-end routing test. It solves the accepted problem (#9101, P2) for users whose model endpoint sits behind an Alibaba Cloud API Gateway, and every line in the diff serves that goal. What keeps this at 4 rather than 5: Verdict: approve. CI on the reviewed commit is still in flight (the ubuntu unit suite), so approval is deferred until CI lands green on 中文说明置信度：4/5 —— 干净、最小的改动，与我的独立方案完全一致，测试套件端到端钉住了验收路径；其余意见均为非阻塞项。 退一步看：方案正是我会写的样子——按既有来源模式加一个点锚定后缀检查及负例，后续提交又补上了对应的调试日志和端到端路由测试。它解决了已被接受的问题（#9101，P2），服务模型端点部署在阿里云 API 网关之后的用户；diff 中每一行都服务于该目标。给 4 分而非 5 分的原因： 结论：批准。审查提交上的 CI 仍在运行（ubuntu 单测套件），因此批准推迟到 — Qwen Code · qwen3.8-max Reviewed at |
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. |
doudouOUC
approved these changes
Aug 13, 2026
doudouOUC
left a comment
doudouOUC
left a comment
Collaborator
There was a problem hiding this comment.
Reviewed at 834d2400 — approving. The change is a faithful, minimal extension of the existing origin-detection shape, and I verified it is actually load-bearing rather than just present.
Verified
- The predicate is right.
hostname.endsWith('.alicloudapi.com')requires a leading label, so the bare domain and lookalikes (evilalicloudapi.com,alicloudapi.com.attacker.test) are all rejected — same posture as the adjacent.alibaba-inc.com/.aliyun-inc.comchecks, and the hostname is taken from a parsedURLso a path-only match likehttps://evil.example/alicloudapi.com/…can't sneak through either. Port-bearing URLs are unaffected becauseURL.hostnameexcludes the port. - All five wiring points are updated consistently: the doc comment, the
isAliCloudApiOriginderivation, the proxy-mismatch warning's negation chain, the new debug line, and the return expression. Missing the negation chain would have produced a spurious "DashScope headers will be skipped" warning on a route that is in fact accepted. - Tests pass and are load-bearing.
npx vitest run src/core/openaiContentGenerator/provider/dashscope.test.ts→ 153 passed in a clean tree at this head. DroppingisAliCloudApiOrigin ||from the return killed 4 cases (bothisDashScopeProvidercases and bothdetermineProviderrouting cases), so the new coverage is not decorative. Routing the assertion throughdetermineProvider+buildRequestrather than onlyisDashScopeProvideris the right choice — it pins the actualmetadatapayload the issue asks for.
Suggestion — the blast radius is wider than the analogy in the description
Risk & Scope says this is "the same trust posture already applied to *.alibaba-inc.com and *.aliyun-inc.com". Those are Alibaba-internal corporate domains; *.alicloudapi.com is a public multi-tenant domain where every Alibaba Cloud API Gateway customer gets a subdomain. So the population of hosts newly classified as DashScope-compatible is "anyone with an Alibaba Cloud account", not "Alibaba internal".
That matters because isDashScopeProvider is not a metadata switch — it selects the whole provider. A base URL matching it also gets X-DashScope-CacheControl/-UserAgent/-AuthType headers, cache_control parts injected into messages and tools, vl_high_resolution_images + preserve_thinking on vision models, the tiered enable_thinking/reasoning_effort/thinking_budget knobs, and deletion of the OpenAI-style nested reasoning object. A user pointing qwen-code at an unrelated strict OpenAI-compatible API that happens to sit behind Alibaba Cloud API Gateway would start receiving all of that, and a strict server can reject the unknown body fields.
No code change requested — the issue asks for domain-level recognition and there is no finer-grained hook today. But I'd (a) reword that Risk & Scope bullet so it doesn't imply equivalent exposure, and (b) note in the docs that DASHSCOPE_PROXY_BASE_URL remains the exact-URL opt-in for a custom gateway, so a user on *.alicloudapi.com who does not want DashScope treatment knows the situation is now the reverse of opt-in.
中文说明
在 834d2400 上完成审查，同意合并。改动是对既有 origin 判定形状的忠实、最小扩展，并且我确认了新增测试是真正起作用的、而非仅仅存在。
已验证
- 判定条件正确：
hostname.endsWith('.alicloudapi.com')要求必须有前置 label，因此裸域名与形近域名（evilalicloudapi.com、alicloudapi.com.attacker.test）全部被拒绝，与相邻的.alibaba-inc.com/.aliyun-inc.com姿态一致；hostname 取自已解析的URL，所以https://evil.example/alicloudapi.com/…这类仅路径匹配也无法绕过。带端口的 URL 不受影响，因为URL.hostname不含端口。 - 五处接线点都同步更新了：文档注释、
isAliCloudApiOrigin推导、代理不匹配告警的取反链、新增 debug 日志、返回表达式。漏掉取反链会在实际被接受的路径上打出误导性的"将跳过 DashScope headers"告警。 - 测试通过且是承重的：干净树上该 head 跑
dashscope.test.ts→ 153 passed。把返回表达式里的isAliCloudApiOrigin ||去掉后有 4 个用例失败（两个isDashScopeProvider用例 + 两个determineProvider路由用例），说明新覆盖不是装饰。断言走determineProvider+buildRequest而不只是isDashScopeProvider，是正确的选择——它固定了 issue 真正要求的metadata载荷。
建议：影响面比描述里的类比更大
Risk & Scope 写的是"与已应用于 *.alibaba-inc.com 和 *.aliyun-inc.com 的信任姿态相同"。但后两者是阿里内部域名，而 *.alicloudapi.com 是公共多租户域名——任何阿里云 API 网关客户都会拿到一个子域名。因此被新纳入"DashScope 兼容"的主机集合是"任何拥有阿里云账号的人"，而不是"阿里内部"。
这一点重要，是因为 isDashScopeProvider 不是一个 metadata 开关，而是选择整个 provider。命中它的 base URL 还会额外获得 X-DashScope-CacheControl/-UserAgent/-AuthType 请求头、注入到 messages 与 tools 里的 cache_control、视觉模型上的 vl_high_resolution_images + preserve_thinking、分档的 enable_thinking/reasoning_effort/thinking_budget，以及删除 OpenAI 风格的嵌套 reasoning 对象。如果用户把 qwen-code 指向恰好部署在阿里云 API 网关后面的、与 DashScope 无关的严格 OpenAI 兼容接口，就会开始收到这一整套，而严格的服务端可能因未知字段直接 400。
不要求改代码——issue 要求的就是域名级识别，目前也没有更细粒度的钩子。但建议：(a) 改写 Risk & Scope 那条，避免暗示暴露面等价；(b) 在文档里说明 DASHSCOPE_PROXY_BASE_URL 仍是自定义网关的精确 URL 选择加入方式，让 *.alicloudapi.com 上不希望被当作 DashScope 处理的用户知道现在的默认已经反过来了。
qwen-code-dev-bot
approved these changes
Aug 13, 2026
qwen-code-dev-bot
left a comment
qwen-code-dev-bot
left a comment
Collaborator
There was a problem hiding this comment.
Reviewed: adds *.alicloudapi.com (Alibaba Cloud API Gateway) to the DashScope provider origins so buildRequest injects session-tracking metadata. Hostname matching is subdomain-only and correctly rejects bare/evil-suffix domains (pinned by tests). End-to-end determineProvider routing + metadata injection covered. Low-risk, consistent with existing origin-match pattern. LGTM.
Collaborator
|
Released in v0.21.12. |
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
4 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.
What this PR does
Recognizes
*.alicloudapi.com(Alibaba Cloud API Gateway) as a DashScope-compatible origin, so that model requests sent through such a gateway include themetadatafield in the request body —sessionId,promptId, andchannelwhen configured — exactly like requests to the official DashScope hosts and internal Alibaba domains already do.Why it's needed
qwen-code injects a request-body
metadatafield used for session tracing and log correlation only when the endpoint is recognized as DashScope-compatible. When the model API is accessed through an Alibaba Cloud API Gateway domain (*.alicloudapi.com), the provider falls back to the default OpenAI-compatible path, which omitsmetadata. This breaks session tracking and log correlation for those requests.Reviewer Test Plan
How to verify
Run the focused provider tests:
Confirm the new
alicloudapi.comcases pass: subdomain and port-bearing URLs are recognized, the bare domain and lookalike domains are rejected.Evidence (Before & After)
N/A — non-user-visible change (request-body field for a new domain).
Test output:
dashscope.test.ts: 151 passed (5 new assertions foralicloudapi.com)pipeline.test.ts: 153 passed (unaffected)tsc --noEmit(core): cleaneslinton the two changed files: cleanTested on
Environment (optional)
Unit tests only (
npm ciin a clean worktree, Node v22).Risk & Scope
*.alicloudapi.comis a public gateway where arbitrary APIs can be deployed, so treating it as DashScope-compatible applies DashScope headers, cache control, andmetadatato every request under that domain. This is the same trust posture already applied to*.alibaba-inc.comand*.aliyun-inc.com.alicloudapi.comdomain is deliberately not matched — gateway endpoints are subdomains, consistent with the existing bare-domain rejection for internal Alibaba domains.Linked Issues
Fixes #9101
中文说明
这个 PR 做了什么
将
*.alicloudapi.com（阿里云 API 网关）识别为 DashScope 兼容来源，使通过该网关发送的模型请求在请求体中携带metadata字段——包括sessionId、promptId以及（配置了时的）channel——与发送到 DashScope 官方主机和阿里内部域名时一致。为什么需要
qwen-code 仅在端点被识别为 DashScope 兼容时，才会在请求体中注入用于会话追踪和日志关联的
metadata字段。当模型 API 通过阿里云 API 网关域名（*.alicloudapi.com）访问时，provider 会回退到默认的 OpenAI 兼容路径，从而不携带metadata，导致这些请求的会话追踪和日志关联中断。评审验证方式
如何验证
运行聚焦的 provider 测试：
确认新增的
alicloudapi.com用例通过：子域名和带端口 URL 被识别，裸域名和仿冒域名被拒绝。证据（Before & After）
N/A —— 非用户可见改动（针对新域名的请求体字段）。
测试输出：
dashscope.test.ts：151 通过（含 5 个alicloudapi.com新增断言）pipeline.test.ts：153 通过（无影响）tsc --noEmit（core）：通过eslint：通过测试环境
环境（可选）
仅单元测试（干净 worktree 中
npm ci，Node v22）。风险与范围
*.alicloudapi.com是公开网关，任意 API 都可能部署其上，因此将其视为 DashScope 兼容会对该域名下的所有请求应用 DashScope 头、缓存控制和metadata。这与已经应用于*.alibaba-inc.com和*.aliyun-inc.com的信任姿态一致。alicloudapi.com有意不匹配——网关端点是子域名，与现有对阿里内部裸域名的拒绝行为保持一致。关联 Issue
Fixes #9101