PR创建成功通知 | 感谢您的贡献 🎉

您好！系统已检测到您成功创建 Pull Request（PR），感谢您对项目的支持与参与！以下几点需要您着重关注：

一、PR必须关联Issue ❗️

触发门禁检查的必要步骤：在PR描述框输入Issue完整链接，完成Issue关联。

请注意，一个 Issue 不能同时关联同一 base 仓库内同一个分支的多个开启状态的 PR

二、门禁触发规则 🔧

1. 门禁类型判定：由Issue关联的PR所属代码仓数量决定
   • 关联多个代码仓PR：触发「多仓联合门禁」
   • 关联单个代码仓PR：触发「单仓门禁」
2. 启动指令与检查范围：需主动回复指令：
   • 回复 "start build"：执行Cangjie的主要基础检查，包含commit格式检查、静态告警分析、OAT开源声明检查、多平台构建、单元/集成测试等
   • 关联同一issue的多个PR，仅需在任意一个PR里回复触发一次门禁，该PR门禁通过后，所有PR都会添加Label和测试人
   • 每个pr只能同时运行一条CI流水线，如需重新启动，请先关闭运行中的，再评论触发门禁
   • Markdown修改仅触发文档类构建测试门禁，不会触发Cangjie的编译测试门禁
   • commit 信息格式请遵循：Conventional Commits 规范
   • 请保证每一条 commit 都已添加 Signed-Off-By 信息

三、合入条件 ⚠️

• 满足最低评审人数，且评审问题需全部解决；
• 禁止合入本人创建的PR，需由其他协作者操作；
• 合并前确保关联流水线任务运行成功（build-test-passed）。

四、合并PR ✅

回复 "start merge"，CI流水线会自动检查所有关联PR的状态、版本号标签、检视意见密度、兼容性，若所有PR都满足合并条件，则将会同时合并所有PR。若存在不满足合并条件的PR，则不会合并任何PR。

如果希望不进行兼容性相关的检测，请任一合法审查人复制以下内容，在 start merge 前提交评论：

本 pr 不需要兼容性相关检测，对于引发的任何兼容性问题（即由于本 pr 合入将导致用户需适配代码的话），由本人承担。

If you wish to avoid compatibility-related checks, please have any approver copy the following content and submit it as a comment before sending start merge:

This PR does not require compatibility-related checks. For any compatibility issues caused by this PR (i.e., if the integration of this PR will require users to adapt their code), I will take full responsibility.

五、补充说明 📢

• 详细仓颉贡献流程：贡献流程(Cangjie Community Contribution)
• 门禁结果将自动评论至关联的所有PR，敬请留意。

start build

start merge

⏳ 正在进行兼容性检测中，可能需要2~3分钟，请稍候，若10分钟无检测结果，请重新回复 start merge。

⏳ Compatibility check in progress. It may take 2–3 minutes. Please wait. If there is no result after 10 minutes, please reply with start merge again.

✅ 合入前兼容性检测通过。
涉及仓库：Cangjie/cangjie_stdx, Cangjie/cangjie_test

结论

• 分析过程：分析了 Cangjie/cangjie_stdx#728：检查了父提交 9b074542049d342e7a42c1fe14d7ba35cc063a20 与 PR head 88ba0f1fdfbb5ddb22361833ec504ce0352841dc 在 src/stdx/net/http/http_client1_1.cj 的差异，并核对 HTTP/1.1 请求体发送、响应读取、异常传播及重连相关路径。 Reviewed Cangjie/cangjie_stdx#728 by comparing the parent commit with the PR head and checking HTTP/1.1 request-body sending, response reading, exception propagation, and reconnect-related paths.
• 原因：兼容。PR 仅调整 ConnNode.sendRequestTimeout 的内部时序：将响应读取和 1xx 处理置于 try 中，并在 finally 中等待 sendRequestBodyTimeout 完成，避免读响应异常传播前重连导致同一 HttpBufferedBody 被并发访问。src/stdx/net/http/http_client1_1.cj 中 sendRequestTimeout 的签名、HttpResponse 返回结构、HTTP/1.1 请求与响应处理、状态码/响应体处理、超时异常和公开 HttpClient.send 调用契约均未改变；新增的 responseOp 兜底异常只覆盖内部不变量失败，不影响正常旧调用。未发现公开 API、ABI、配置或旧成功场景回退；该变更属于对异常/竞态路径的兼容性修复。 Compatible. The PR only changes internal sequencing in ConnNode.sendRequestTimeout: response reading and 1xx processing remain in place while finally waits for sendRequestBodyTimeout, preventing reconnect-time concurrent access to the same HttpBufferedBody. The method signature, HttpResponse contract, HTTP/1.1 request and response handling, status/body processing, timeout behavior, and public HttpClient.send path remain unchanged. The new responseOp fallback only covers an internal invariant failure and does not affect normal old calls. No public API, ABI, configuration, or old successful-use regression was found; this is a compatibility-preserving concurrency fix.
• 结论：兼容

✅ 以下PR将同时合入：

• Cangjie/cangjie_stdx#728: fix(http): prevent concurrent access to HttpBufferedBody in http1.1 client
• Cangjie/cangjie_test#2034: fix(net): client1.1 reconnect avoid write body concurrency

✅ The following PRs will be merged simultaneously:

• Cangjie/cangjie_stdx#728: fix(http): prevent concurrent access to HttpBufferedBody in http1.1 client
• Cangjie/cangjie_test#2034: fix(net): client1.1 reconnect avoid write body concurrency