fix(core): Include request IDs in OpenAI error logs - #6379
Conversation
E2E test reportTested with real OpenAI-compatible providers and Scenario 1, DashScope 401 before/after: using an intentionally invalid key against the real DashScope endpoint, the globally installed Scenario 2, Token Plan Additional local checks already run: focused OpenAI logger unit tests, logging content generator tests, Prettier check, build, typecheck, and bundle build. |
|
Thanks for the PR, @tanzhenxin! Template looks good ✓ — all required sections present with real before/after evidence. Problem: observed, well-documented. The PR shows real DashScope 401 and Token Plan 429 scenarios with concrete JSON output — Direction: aligned. The Approach: minimal and focused. Two files, +74/-6. The extraction logic is clean: check common SDK property names ( 中文说明感谢贡献,@tanzhenxin! 模板完整 ✓ — 所有必填章节齐全,附带真实的 before/after 证据。 问题:已观测,文档充分。 PR 展示了真实的 DashScope 401 和 Token Plan 429 场景,附带具体 JSON 输出——main 分支缺少 方向:对齐。 方案:精简聚焦。 2 个文件,+74/-6。提取逻辑简洁:检查常见 SDK 属性名( — Qwen Code · qwen3.7-max |
Code ReviewThe implementation is clean and well-targeted:
No correctness issues, no security concerns, no convention violations found. The diff is minimal and every line serves the stated goal. Unit TestsAll 40 tests pass, including the 2 new ones. Typecheck clean. Before/After (tmux verification)Ran a verification script against main branch (before) and PR branch (after) using three error scenarios: Before (installed build, main branch)After (this PR)Tests 1 and 2 now surface the — Qwen Code · qwen3.7-max |
|
This is a textbook example of a well-scoped diagnostic enhancement. The problem is real and well-evidenced (real provider errors, real JSON output), the solution is minimal (2 files, +74/-6, no abstractions), and the implementation reuses existing infrastructure ( My independent proposal would have been: "check The before/after tmux test confirms the change works for both SDK-level errors (direct Unit tests: 40/40 pass. Typecheck clean. Author provided real-provider evidence (DashScope 401, Token Plan 429). Ships it. ✅ 中文说明这是一个范围合理的诊断增强 PR 的典范。问题是真实且有充分证据的(真实 provider 错误、真实 JSON 输出),方案精简(2 个文件,+74/-6,无抽象),实现复用了已有基础设施( 我的独立方案会是:"检查 before/after tmux 测试确认了对 SDK 级别错误(直接的 单元测试:40/40 通过。类型检查通过。作者提供了真实 provider 证据(DashScope 401、Token Plan 429)。 批准合并 ✅ — Qwen Code · qwen3.7-max |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
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. |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
No issues found. LGTM! ✅
Downgraded from Approve to Comment: CI still running.
— qwen3.7-max via Qwen Code /review
What this PR does
This PR adds the upstream request correlation id to OpenAI-compatible interaction logs when a chat-completions call fails. The log still records the same request, response, error message, and stack fields as before, but now also includes
error.requestIdwhen the provider or SDK exposes one.Why it's needed
When DashScope or other OpenAI-compatible providers return server-side errors, support and incident debugging depend on the provider request id rather than the successful completion id. Successful calls may have a
chatcmpl-...response id, but failed calls often only expose a header or body request id. Without this field in--openai-loggingoutput, users have to reproduce the failure with lower-level tooling or inspect SDK internals to give provider support a useful correlation id.Reviewer Test Plan
How to verify
Run
--openai-loggingagainst an OpenAI-compatible endpoint that returns an error and confirm the generated interaction log includeserror.requestId. I verified this with two real provider scenarios and no mock server: a standard DashScope 401 error and a Token Planglm-5.2429 quota error.Scenario 1, real DashScope 401 before/after: I used an intentionally invalid key against the real DashScope OpenAI-compatible endpoint. The before run used the globally installed
qwen 0.19.6; the after run used the local bundled CLI.Scenario 2, real Token Plan
glm-5.2429: I used the real Token Plan provider withglm-5.2andTOKEN_PLAN_API_KEY, which returned the expected quota-exhausted 429 error.Evidence (Before & After)
Scenario 1 before, with globally installed
qwen 0.19.6against real DashScope using an intentionally invalid API key:{ "response": null, "errorKeys": ["message", "stack"], "errorRequestId": null }Scenario 1 after, with the local bundled CLI against the same real DashScope endpoint:
{ "response": null, "errorKeys": ["message", "stack", "requestId"], "errorRequestId": "92aee7f0-2624-922d-90e0-5dc7fd5b5a6f" }Scenario 2 after, with real Token Plan
glm-5.2and a quota-exhaustedTOKEN_PLAN_API_KEY:{ "request": { "model": "glm-5.2" }, "response": null, "error": { "message": "429 Your token-plan quota has been exhausted.", "requestId": "b539561e-6183-4cd1-b906-cd1460ccaf05" } }Tested on
Environment (optional)
Node.js v22.12.0 on macOS. E2E used real DashScope and Token Plan OpenAI-compatible endpoints with
--openai-loggingand temporary runtime/log directories; no mock server was used.Risk & Scope
Linked Issues
N/A
中文说明
What this PR does
这个 PR 会在 OpenAI 兼容接口的聊天补全调用失败时,把上游请求关联 ID 写入交互日志。日志仍然保留原有的请求、响应、错误消息和堆栈字段,但当 provider 或 SDK 暴露请求 ID 时,现在会额外包含
error.requestId。Why it's needed
当 DashScope 或其他 OpenAI 兼容 provider 返回服务端错误时,排查和联系支持通常需要 provider 请求 ID,而不是成功响应里的 completion id。成功调用可能有
chatcmpl-...响应 ID,但失败调用通常只暴露 header 或 body 中的请求 ID。之前--openai-logging输出里没有这个字段,用户需要用更底层的工具复现问题或检查 SDK 内部状态,才能拿到可用于 provider 排查的关联 ID。Reviewer Test Plan
How to verify
对会返回错误的 OpenAI 兼容 endpoint 运行
--openai-logging,确认生成的交互日志包含error.requestId。我用两个真实 provider 场景做了验证,没有使用 mock server:标准 DashScope 401 错误,以及 Token Planglm-5.2的 429 配额错误。场景 1,真实 DashScope 401 before/after:我用故意无效的 key 访问真实 DashScope OpenAI 兼容 endpoint。before 使用全局安装的
qwen 0.19.6;after 使用本地 bundled CLI。场景 2,真实 Token Plan
glm-5.2429:我使用真实 Token Plan provider、glm-5.2和TOKEN_PLAN_API_KEY,该 key 返回了预期的配额耗尽 429 错误。Evidence (Before & After)
场景 1 before,使用全局安装的
qwen 0.19.6和故意无效的 API key 访问真实 DashScope:{ "response": null, "errorKeys": ["message", "stack"], "errorRequestId": null }场景 1 after,使用本地 bundled CLI 访问同一个真实 DashScope endpoint:
{ "response": null, "errorKeys": ["message", "stack", "requestId"], "errorRequestId": "92aee7f0-2624-922d-90e0-5dc7fd5b5a6f" }场景 2 after,使用真实 Token Plan
glm-5.2和配额耗尽的TOKEN_PLAN_API_KEY:{ "request": { "model": "glm-5.2" }, "response": null, "error": { "message": "429 Your token-plan quota has been exhausted.", "requestId": "b539561e-6183-4cd1-b906-cd1460ccaf05" } }Tested on
Environment (optional)
macOS 上的 Node.js v22.12.0。E2E 使用真实 DashScope 和 Token Plan OpenAI 兼容 endpoint、
--openai-logging和临时 runtime/log 目录;未使用 mock server。Risk & Scope
Linked Issues
N/A