fix(java): avoid Java 11 HTTP fixture reuse - #10365
Conversation
|
✅ Qwen Triage finished — CI landed green on ✅ Qwen Triage 已完成 —— |
|
Thanks for the PR! Template looks good ✓ Problem: observed flake, verified. I pulled the linked job (run 33140800515, Direction: aligned — CI reliability for the Java SDK matrix, no product behavior touched. The PR also correctly refuses the tempting alternative (adding a production retry around cancel/detach): those mutations are outcome-unknown, and blindly retrying them risks double-execution. CHANGELOG has no direct reference, which is expected for a test fixture. Size: not applicable — not a core path; single Java test file, 15 lines (13 additions / 2 deletions), all test code. Approach: scope feels exactly right. Risk: no high-risk paths matched; no elevated risk signals. Moving on to code review. 🔍 中文说明感谢贡献! 模板完整 ✓ 问题:已观测到的 flake,且已核实。拉取了关联的失败任务(run 33140800515, 方向:对齐——Java SDK 矩阵的 CI 稳定性修复,不触碰任何产品行为。PR 也正确地拒绝了看似诱人的替代方案(在生产代码中为 cancel/detach 加重试):这些变更操作是结果未知语义,盲目重试可能导致重复执行。CHANGELOG 无直接引用,对测试夹具改动而言符合预期。 规模:不适用——未触及核心路径;单个 Java 测试文件,共 15 行(+13/−2),全部为测试代码。 方案:范围恰到好处。仅在那一个 flaky 测试的三个端点(cancel + 两个 detach)上设置 风险:未命中高风险路径;无升级风险信号。 进入代码审查 🔍 — Qwen Code · qwen3.8-max Reviewed at |
Code reviewMy independent proposal before reading the diff: for a Java 11-only keep-alive flake on the fixture's mutation endpoints, mark the affected responses
Testing — PR's own CI (unattended run: no PR code built or executed here)Final CI results for
One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行(取最新一次运行),省略 skipped,失败项排在最前。
Sandboxed verification would settle this: 中文说明代码审查看 diff 之前我的独立方案:针对只出现在 Java 11 上、发生在夹具变更端点的 keep-alive flake,应在夹具侧给受影响的响应标记
测试——来自 PR 自身 CI(无人值守运行:此处未构建或执行任何 PR 代码)上方表格为 PR 自身 CI 检查的真实名称与结论。
沙箱验证可以补齐这一点: — Qwen Code · qwen3.8-max Reviewed at |
|
Confidence: 4/5 — verified flake, minimal correctly-scoped fix, clean review; the only reservation is that one green Java 11 run cannot yet prove an intermittent flake is gone. Stepping back: the problem is real and verified end to end — the linked job log shows the exact test, the exact EOF signature, failing on exactly the detach endpoint this PR changes. The implementation is the smallest version of what I would have done myself, and the author considered the one genuine alternative (production retry) and rejected it for the right reason: cancel/detach are outcome-unknown mutations, and retrying them could double-execute. The coverage tradeoff — this one test no longer exercises keep-alive reuse for cancel/detach — is stated honestly, bounded to a single test, and worth a stable matrix. The Java 17 red is runner infrastructure, verified from the job log, not something this PR can or should fix. Nothing here is trying too hard. In six months this reads as a boring, correct flake fix. Verdict: approve — but two CI runs are still in flight ( 中文说明置信度:4/5 —— flake 已核实,修复最小且范围正确,审查干净;唯一的保留意见是单次 Java 11 绿色结果尚不能证明间歇性 flake 已消失。 整体来看:问题真实存在且已端到端核实——关联 job 日志显示了完全相同的测试、完全相同的 EOF 特征,失败点正是本 PR 修改的 detach 端点。实现是我自己也会采用的最小方案;作者认真考虑过唯一真正的替代方案(生产重试)并正确地拒绝了它:cancel/detach 是结果未知的变更操作,重试可能导致重复执行。覆盖取舍——该测试不再覆盖 cancel/detach 的 keep-alive 复用——已被如实说明、限定在单个测试内,换取矩阵稳定是值得的。Java 17 的红色是运行器基础设施问题,已从 job 日志核实,不属于本 PR 能或应修复的范围。 没有任何过度设计。六个月后回看,这就是一次朴素、正确的 flake 修复。结论:批准——但还有两个 CI 运行( — Qwen Code · qwen3.8-max Reviewed at |
|
@qwen-code /verify |
|
Sandboxed verification: The verification job did not complete (checkout, runner, or setup error) and produced no report. See the workflow run for details. 中文 — 判定:
|
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.
LGTM, looks ready to ship — CI landed green after the review. ✅
chiga0
left a comment
There was a problem hiding this comment.
Scope: DaemonSessionClientTest.java only (+13 / -2). Test fixture change, no production code touched.
Checked: server lifecycle (@BeforeEach creates a fresh HttpServer instance, @AfterEach calls server.stop(0) — no cross-test context contamination) · noContentAndCloseConnection() vs existing noContent() (correctly adds Connection: close before sendResponseHeaders) · cancel handler inline vs helper (inline is correct because of the cancelReceived.countDown() requirement) · other tests registering /session/session-2/detach — each runs on its own fresh server instance.
CI: Java 11 ✅ / Java 17 ✅ / Java 21 ✅ (ubuntu) · macOS Java 21 ✅ · Windows Java 21 ✅ · Real daemon E2E Java 11 ✅. The original failure path is confirmed fixed.
Cross-check: CI bot approved "LGTM, looks ready to ship." No disagreements found.
No blockers. The fix is correctly scoped — Connection: close on the cancel and detach responses prevents Java 11 HttpClient from attempting connection reuse against the in-process fixture, which is the right fix for the EOF flake without touching production retry behavior.
Reviewed with AI assistance.
|
Released in v0.22.3. |
…wenLM#10472) The Java 11 lane of SDK Java fails intermittently in the daemon client tests: a session teardown raises DetachOutcomeUnknownException or MutationOutcomeUnknownException wrapping "HTTP/1.1 header parser received no bytes". It has hit five different test methods over the past day on unrelated branches, while Java 17, Java 21, macOS and Windows stay green in the same runs. The fixture causes it. On Java 11 the JDK's own HTTP server drops the connection after a response with no body at all -- a 204 detach, a 204 cancel, a 204 session delete, an empty event stream -- while the Java 11 HttpClient keeps that connection pooled. The next mutation the SDK sends over it reads EOF before any response byte, and since the request is not idempotent the SDK correctly declines to retry and reports the outcome as unknown. Pairing the halves across JDKs shows both must be Java 11: a Java 11 server with a Java 21 client never fails, nor does a Java 21 server with a Java 11 client, so only the fixture is affected. Route every body-less response through a helper that marks the response non-persistent, so the client never pools a connection the fixture is about to drop. This generalises QwenLM#10365, which applied the same treatment to two handlers of a single test. On Java 11, pinned to one core: the three test methods seen failing in CI failed 50 of 200 rounds before this change and 0 of 200 after.
What this PR does
This PR makes the slow-session-creation concurrency test close its HTTP connection after cancel and detach responses. The change is limited to that test fixture and does not alter production request or retry behavior.
Why it's needed
Main failed intermittently on Ubuntu Java 11 with
HTTP/1.1 header parser received no byteswhile the Java 17, Java 21, macOS, Windows, and real-daemon jobs passed. The same test and EOF signature have appeared on unrelated changes, indicating connection reuse between Java 11HttpClientand the in-processHttpServerfixture rather than a product regression. Example: https://github.com/QwenLM/qwen-code/actions/runs/33140800515/job/98750998297Reviewer Test Plan
How to verify
Run the slow-session-creation test repeatedly with Java 11 and confirm cancel plus both session detach operations complete without an EOF from the HTTP header parser. Run the same focused test with Java 17 or newer as a control. The GitHub Java matrix should remain green across all configured JDK versions.
Evidence (Before & After)
N/A — test-fixture-only change. Before this change, the Java 11 matrix intermittently failed during session cleanup; after this change, the fixture does not reuse those HTTP connections.
Tested on
Environment (optional)
Local Java and Maven runtimes were unavailable.
git diff --checkpassed, and the complete GitHub SDK Java matrix passed: https://github.com/QwenLM/qwen-code/actions/runs/33148076915Risk & Scope
Linked Issues
N/A
中文说明
本 PR 的改动
本 PR 让慢速会话创建并发测试在 cancel 和 detach 响应后关闭 HTTP 连接。改动仅限该测试夹具,不修改生产请求或重试行为。
为什么需要
Main 在 Ubuntu Java 11 上偶发失败并报告
HTTP/1.1 header parser received no bytes,同时 Java 17、Java 21、macOS、Windows 和真实 daemon 任务均通过。相同测试和 EOF 特征曾出现在无关改动上,说明问题来自 Java 11HttpClient与进程内HttpServer测试夹具之间的连接复用,而不是产品回归。示例:https://github.com/QwenLM/qwen-code/actions/runs/33140800515/job/98750998297Reviewer 测试计划
如何验证
使用 Java 11 重复运行慢速会话创建测试,确认 cancel 和两个会话的 detach 操作都能完成,且 HTTP header parser 不再出现 EOF。使用 Java 17 或更高版本运行相同的聚焦测试作为对照。GitHub Java 矩阵应在所有配置的 JDK 版本上保持绿色。
前后证据
不适用——这是仅测试夹具的改动。改动前,Java 11 矩阵会在会话清理期间偶发失败;改动后,该夹具不会复用这些 HTTP 连接。
测试平台
环境(可选)
本地没有可用的 Java 和 Maven 运行时。
git diff --check已通过,完整 GitHub SDK Java 矩阵也已通过:https://github.com/QwenLM/qwen-code/actions/runs/33148076915风险与范围
关联 Issue
不适用