[Bug-Report|缺陷反馈]: 【2026 HCCL通信库创新大赛-粤港澳赛区】【XDU】ReduceScatter BIRS 多层忽略通信返回值导致失败后仍继续执行-hccl-AtomGit

已关闭

[Bug-Report|缺陷反馈]: 【2026 HCCL通信库创新大赛-粤港澳赛区】【XDU】ReduceScatter BIRS 多层忽略通信返回值导致失败后仍继续执行 #324

dididi创建于 7月22日关闭于 8月3日

dididi

7月22日创建

Thanks for sending an issue! Please fill in the following template to help quickly solve your problem.

Describe the current behavior / 问题描述 (Mandatory / 必填)

实验性 ReduceScatter BIRS 模板在单机和多机路径中存在两层返回值丢失：

底层 HcommWriteOnThread()、HcommWriteReduceOnThread() 等通信接口返回 int32_t，项目其他算法通过 CHK_RET(static_cast<HcclResult>(...)) 检查；BIRS 的多处调用却直接丢弃返回值，并继续下发 Notify。
BIRS 内部的 HCCSProcessMainLoop()、SIOProcessMainLoop()、LocalCopyMainLoop()、FinalStep()、PreprocInterServer()、InterServer() 均返回 HcclResult，但上层 RunAsync() 再次直接调用而不检查返回值。

这意味着即使 HCOMM 写、写归约、本地拷贝或内部阶段明确返回失败，BIRS 仍可能继续执行后续同步和数据处理，最后从 RunAsync() 返回 HCCL_SUCCESS。在部分 rank 失败、其他 rank 继续等待 Notify 的情况下，还可能表现为错误结果或通信超时，而原始错误被覆盖。

关键代码：

单机 HCCS 写与 SIO 写归约未检查返回值：https://gitcode.com/cann/hccl/blob/171f2ba3aee0dea7df63e7c0af8efd9843c265b1/experimental/ops/reduce_scatter/birs/template/reduce_scatter_birs.cc#L124-L157
单机 RunAsync() 忽略三个循环阶段和 FinalStep() 的 HcclResult：https://gitcode.com/cann/hccl/blob/171f2ba3aee0dea7df63e7c0af8efd9843c265b1/experimental/ops/reduce_scatter/birs/template/reduce_scatter_birs.cc#L228-L250
多机模板同样直接丢弃写返回值：https://gitcode.com/cann/hccl/blob/171f2ba3aee0dea7df63e7c0af8efd9843c265b1/experimental/ops/reduce_scatter/birs/template/reduce_scatter_birs_inter.cc#L62-L97 、https://gitcode.com/cann/hccl/blob/171f2ba3aee0dea7df63e7c0af8efd9843c265b1/experimental/ops/reduce_scatter/birs/template/reduce_scatter_birs_inter.cc#L139-L170
多机 RunAsync() 忽略 PreprocInterServer() 和 InterServer() 返回值：https://gitcode.com/cann/hccl/blob/171f2ba3aee0dea7df63e7c0af8efd9843c265b1/experimental/ops/reduce_scatter/birs/template/reduce_scatter_birs_inter.cc#L206-L229
通用数据传输 wrapper 对同类接口使用 CHK_RET：https://gitcode.com/cann/hccl/blob/171f2ba3aee0dea7df63e7c0af8efd9843c265b1/src/ops/op_common/template/wrapper/alg_data_trans_wrapper.cc#L260-L275 、https://gitcode.com/cann/hccl/blob/171f2ba3aee0dea7df63e7c0af8efd9843c265b1/src/ops/op_common/template/wrapper/alg_data_trans_wrapper.cc#L414-L430

Environment / 环境信息 (Mandatory / 必填)

仓库：cann/hccl
分支：master
基线：171f2ba3aee0dea7df63e7c0af8efd9843c265b1
模块：experimental/ops/reduce_scatter/birs，单机与多机 BIRS template
入口条件：ENABLE_EXPERIMENTAL=ON、HCOMM 版本满足实验接口要求、HCCL_BIRS_ENABLE=TRUE，并由实验选择器选中 ReduceScatter BIRS
问题类型：通信错误码丢失 / 错误后继续执行 / 结果错误或同步超时
验证条件：已完成固定基线源码和返回值传播链核验；当前无昇腾设备，未进行多卡硬件动态复现

Steps to reproduce the issue / 重现步骤 (Mandatory / 必填)

建议在现有 SimWorld/HCOMM stub 中增加一次性失败注入：

构造能够进入 ReduceScatterBIRS::RunAsync() 的合法 BIRS 用例（例如现有 A3 BIRS ST 的 rank 配置）。
让第一次 HcommWriteOnThread() 返回非零错误码，例如 HCCL_E_INTERNAL；其余 stub 保持原行为。
当前 HCCSProcessMainLoop() 丢弃该返回值，继续执行 Notify Record/Wait，并返回 HCCL_SUCCESS。
即使改为让 LocalCopyMainLoop() 内部的 HcommLocalCopyOnThread() 返回失败，该 helper 会返回错误，但 RunAsync() 又丢弃 helper 的 HcclResult，继续下一阶段。
对 HcommWriteReduceOnThread()、FinalStep() 以及多机 PreprocInterServer()/InterServer() 做同样注入，可观察到相同的错误传播断裂。

最小断言：任一数据传输或内部阶段返回非成功时，RunAsync() 必须立即返回相同错误，且失败点之后不再下发新的 Notify、写或本地拷贝任务。

Describe the expected behavior / 预期结果 (Mandatory / 必填)

对所有返回 int32_t 的 HCOMM 数据传输接口使用 CHK_RET(static_cast<HcclResult>(...))，与通用 wrapper 保持一致。
对所有返回 HcclResult 的 BIRS helper 使用 CHK_RET(...)，确保错误逐层传播到 RunAsync() 和算子入口。
一旦数据传输失败，停止依赖该数据的后续 Notify/归约/拷贝操作，保留首个有效错误码。
为单机和多机 BIRS 分别补充失败注入 UT，至少覆盖 Write、WriteReduce、LocalCopy 和 helper 层返回失败，并断言失败后无继续下发。

单机路径的确定性返回值链：

HcommWriteOnThread() -> error
  -> return value discarded in HCCSProcessMainLoop()
  -> Notify Record/Wait continues
  -> HCCSProcessMainLoop() returns HCCL_SUCCESS
  -> RunAsync() also discards helper result

HcommLocalCopyOnThread() -> error
  -> LocalCopyMainLoop() returns error via CHK_RET
  -> RunAsync() discards LocalCopyMainLoop() result
  -> later phases continue

多机路径的确定性返回值链：

HcommWriteOnThread() -> error (InterServer)
  -> return value discarded
  -> InterServer() may return HCCL_SUCCESS
  -> RunAsync() discards InterServer() result in all cases
  -> RunAsync() reaches HCCL_SUCCESS

该问题为通信错误传播缺陷，不涉及 UI，无需截图。当前没有昇腾硬件日志，以上结论来自固定基线源码和可在现有 stub 中注入错误的确定性控制流。