APITest 测试修复：修复被外部强杀时的 checkpoint 遗留问题

[cangtianhuang]

背景

当前 PaddleAPITest 的 engineV2 / engineV4 在批量执行 API case 时，原先会在 worker 开始执行 case 后较早写入 checkpoint。这样在一些非正常中断场景下会产生不一致：

• case 实际还没有完成，但已经被写入 checkpoint
• worker 被外部 SIGKILL / SIGTERM 杀掉后，下一次 resume 会错误跳过该 case
• result log 中可能残留没有 checkpoint 对应项的结果行，影响后续统计和续跑判断
• engineV4 的 compute-sanitizer 子进程 crash 与 worker 本身 crash 的语义不够清晰
• compute-sanitizer 的最终错误码与 case 自身测试结果是不同维度：case 可能已写出 pass / error 结果，但 sanitizer 随后报告 CUDA runtime 问题，导致结果日志出现冲突分类

本 PR 调整了 checkpoint 写入语义，只有主进程确认 case 已经完成结果归档/分类后，才将该 case 写入 checkpoint。engineV2 / engineV4 对外部 kill 都不写 checkpoint，使该 case 在下一次运行中重新进入待测集合；engineV4 不在当前运行中立即重试，避免持续 kill 的 case 阻塞当前批次。

同时，engineV4 的 compute-sanitizer 模式改为从源头隔离子进程结果日志：sanitizer child 不再直接写入主结果日志目录，而是先写入 case 级隔离日志目录；只有当 sanitizer 返回码表明子进程结果可采信时，父 worker 才将隔离日志合并回主 .tmp 日志。若 sanitizer 报告错误，则丢弃隔离日志，由主进程写入唯一的 cuda_error 分类，避免先产生冲突再做事后去重。

主要变更

1. 调整 engineV2 checkpoint 写入时机

• 移除 run_test_case() 开始阶段的 checkpoint 写入。
• 将 checkpoint 写入移动到主进程处理 future 结果之后。
• 对 worker 被外部 SIGKILL / SIGTERM 杀掉的场景特殊处理：
  • 不写 checkpoint；
  • 打印 warning；
  • case 会在下一次运行中重新进入待测集合。
• timeout、普通 crash、error 等已经完成分类的结果仍然会写 checkpoint。

2. 调整 engineV4 checkpoint 与 external kill 处理

• 与 engineV2 一致，移除 run_test_case() 开始阶段的 checkpoint 写入。
• 主循环在完成 done / timeout / crashed / error 分类后统一写 checkpoint。
• 对外部 SIGKILL / SIGTERM 场景：
  • 不写结果日志；
  • 不写 checkpoint；
  • 不在当前运行中立即重试，避免单个持续被 kill 的 case 阻塞整轮任务；
  • case 会在下一次运行中重新进入待测集合。

3. 改进 engineV4 compute-sanitizer crash 语义

• compute-sanitizer child 进程非预期退出时，向主进程消息中携带 crash_source="child"。
• 主进程可以区分：
  • sanitizer child crash；
  • worker 进程 crash。
• sanitizer child crash 时，worker 仍可被视为可复用，减少不必要的 worker restart。

4. 隔离 compute-sanitizer 子进程结果日志

• sanitizer child 的日志不再直接写入主 TEST_LOG_PATH/.tmp。
• 每个 sanitizer case 会使用独立隔离日志目录：
  • TEST_LOG_PATH/.tmp/sanitizer/slot_<slot>_<pid>/...
• 父 worker 根据 sanitizer child 的最终 return code 决定是否合并隔离日志：
  • 0、2：子进程流程完整走到 wrapper 层，隔离 .tmp 产物合并回主 .tmp，后续仍由现有 aggregate_logs() 统一聚合；
  • 98、99、sanitizer error exitcode 或其它非零退出：不合并隔离结果日志，由主进程写入最终分类。
• 当 compute-sanitizer 报告 CUDA runtime 错误时，即使 case 功能/数值测试本身通过，也只写入唯一的 cuda_error，避免同一 config 同时出现在 pass 和 cuda_error 等多个结果日志中。
• sanitizer child 的 stdout/stderr 始终由父 worker relay 到主输出日志；丢弃的是隔离结果分类日志，不丢弃有效打印输出。
• sanitizer child 不再重复打印主进程级 Options / Paddle 版本信息，避免每个 case 在主日志中重复出现启动参数。
• compute-sanitizer 隔离目录会在批量测试启动和结束时清理，避免 .tmp/sanitizer 残留。

5. 新增 stale result log 清理逻辑

在 tester/api_config/log_writer.py 中新增 cleanup_uncheckpointed_result_logs()：

• 启动批量测试时，先聚合 .tmp 日志；
• 再清理没有 checkpoint 对应项的 result log 行；
• 只保留同时存在于 checkpoint.txt 的终态日志行；
• 如果 checkpoint.txt 不存在，则跳过清理，避免误删历史结果日志；
• 避免上次异常中断后留下“有结果日志但没有 checkpoint”的脏数据。

清理范围覆盖除 checkpoint 外的各类结果日志，例如 pass、paddle error、accuracy error、timeout、crash、OOM、CUDA error 等。

行为变化

checkpoint 语义变化

变更前：

• checkpoint 更接近“case 已经开始执行”。

变更后：

• checkpoint 更接近“case 已经被主进程确认完成归档/分类”。

这能避免 case 尚未完成归档/分类时被提前 checkpoint；外部 kill case 不写 checkpoint，会在下次运行中重试。

external kill 处理策略

• engineV2：外部 kill 后不写 checkpoint，case 在下一次运行中重试。
• engineV4：外部 kill 后不写结果日志、不写 checkpoint，也不在当前运行中立即重试；case 在下一次运行中重试，当前批次继续调度后续 case。

compute-sanitizer 结果归档策略

• sanitizer child 的功能/数值测试结果先写入隔离目录，作为候选结果。
• returncode == 0 或 returncode == 2 时，隔离结果合并回主日志。
• sanitizer 报告运行时错误时，隔离结果被丢弃，主进程只归档 cuda_error。
• returncode == 98 / 99 等 fatal 退出不再合并隔离结果日志，分别由主进程归档为 oom / cuda_error。
• sanitizer child 的有效打印输出始终保留在主输出日志中；互斥约束只作用于结果分类日志。
• 主日志只保留主进程级启动参数，避免每个 sanitizer child 重复输出 Options。
• .tmp/sanitizer 隔离目录在批量测试启动和结束时自动清理。
• 这样从源头避免结果日志冲突，而不是依赖后续重复检查或事后去重。

result log 恢复策略

• 每次启动批量测试时会清理无 checkpoint 对应项的 stale result rows。
• result log 与 checkpoint 的一致性更强，续跑和统计结果更可靠。