问题描述

在 cann/runtime 的 CloseSubProcList 实现中，非空列表会按每批 50 条发送。
当列表长度恰好为 50 时，第一批 50 条已经成功处理，但实现仍然无条件执行一次
余数批次。余数为 0，而内部 ExecuteClosePidList 明确将零计数视为非法参数，
导致本来满足接口非空和最大数量限制的请求返回 TSD_INTERNAL_ERROR。

该行为还可能造成调用方看到“关闭失败”，但设备端已经收到并处理了第一批 50
个子进程的关闭消息，产生返回状态与实际副作用不一致的问题。

环境信息

• 仓库/commit：cann/runtime，681ef7610df13c8128982901142a2c869ddbb53e
• OS/架构：Linux 5.10/aarch64
• Ascend 硬件：Ascend 910B3；本次使用 Host TSD client 单元测试桩
• Driver/Toolkit/OPP：Driver 25.5.2；Toolkit/OPP 9.1.0；源码为 9.2 开发线
• 编译器和 Python：G++ 11.4.0、Python 3.12.13

重现步骤

1. 构建 tsd_client_utest。
2. 启用批量关闭能力，构造 50 个合法的 ProcStatusParam，调用
   CloseSubProcList(closeList, 50)；让通信响应和 WaitRsp 返回成功。
3. 使用 49 条和 51 条列表作为边界对照。
4. 观察返回值和测试桩记录的消息批次数量。

预期结果

50 条列表应发送一个包含 50 条记录的批次并返回 TSD_OK。恰好达到批次上限
不应被当作空列表，也不应执行零计数请求。

实际结果

50 条列表的第一个批次包含 50 条记录并成功发送，但函数随后调用
ExecuteClosePidList，其 pidCnt 为 0；该内部参数检查返回错误，最终
CloseSubProcList 返回 TSD_INTERNAL_ERROR。临时将用例期望改为 TSD_OK 时，
断言失败显示实际值为 1、期望值为 0。

对照结果：49 条返回成功且只发送 49 条；51 条返回成功且发送 50 条和 1 条两个
批次。固定 commit 的 6 个相关单元测试全部通过实际行为断言。

日志/最小复现

构建命令：cmake --build source/build2 --target tsd_client_utest -j2，退出码 0。

运行命令：

source/build2/tests/ut/tsd/tsdclient/tsd_client_utest \
  --gtest_color=no \
  --gtest_filter='SubProcessControllerTest.CloseSubProcList_*:SubProcessControllerTest.OpenAndCloseHccp_*'

最终实际行为退出码为 0，6/6 用例通过；反向期望成功的单用例退出码为 1，
输出包含 Which is: 1 与 TSD_OK 的 Which is: 0。

影响与规避方式

影响：调用方无法根据返回值判断设备端是否已完成全部列表处理；在恰好 50 条时，
第一批可能已经产生关闭副作用而调用仍报告失败。发生错误后上层重试还可能造成
重复关闭请求或额外错误日志。

临时规避：将列表拆成不是 50 的整批长度，例如 49 条或 51 条（由调用方按更小
批次拆分）；这不是接口应有的要求。由于本次源码为 9.2 开发线、运行 Toolkit
为 9.1.0，尚未宣称匹配版本 NPU 端到端规避效果。

建议的回归测试

增加 listSize=1、49、50、51、100 的批量边界回归用例，断言每次发送的批次
数量和大小、返回状态以及零计数批次不会被调用。特别断言 50 和 100 条输入均
成功，并覆盖通信响应成功和失败的路径。