自动化失败、重试与停止

返回 Codex 教学总目录

目标与前置材料

本段提到的教学与资源: JSON／JSONL 篇 · 排程篇

步骤 1：先辨认工作状态

排程有保存的设定，每次触发则有各自的 run；暂停设定不等于取消正在跑的那次，删除排程也不代表回复它已造成的修改。本机脚本的 timeout 只表示包装程式等到上限；网页显示离线只表示连线不可用。两者都不足以断言远端或子程序完全停止。先记下任务／排程名称、主机、资料夹、时区、输入版本、最后一次开始时间与可见的执行编号，再决定下一步。

成功回答可能已存在于旧档案，所以档案存在本身不是成功状态。

步骤 2：重现『有答案，但没有完成证据』

用档案管理员将成功的 run-01 完整复制成 recovery-running。只在副本 status.json 改成下方内容，保留原本正确的 final.json 与事件档。这是明确标记的模拟中断，不要修改真实失败纪录来假装成功。接著在原练习资料夹执行 verify-only；Windows 用 PowerShell，macOS／Linux 用各自终端机。预期 Not accepted: Process did not exit successfully，退出非 0。

{
  "state": "running"
}

py -3 run_summary.py recovery-running --verify-only
$LASTEXITCODE

python3 run_summary.py recovery-running --verify-only
echo $?

另复制原始 run-01 成 recovery-timeout，只把 status.json 换成 {"state":"timeout"}，用新资料夹名称再验证，也必须失败。这两个案例证明即使回答看来正确，缺乏完成证据仍不能采用。最后对未变更的 run-01 执行同一条 verify-only，应重新通过。把三个结果写入纪录，明确注明是副本演练；这不等于真的让主机离线或真的发生模型逾时。

步骤 3：处理真正的逾时或离线

若使用桌面排程，先到 Scheduled 暂停同一项，避免新的触发，再打开已有 run 看是否仍活动。主机离线时先恢复电源、网路、程式与资料夹；回到原任务核对最后动作与结果，不立刻新建另一份相同排程。Windows、macOS、Linux 都使用自己那台主机的状态，不以手机仍看得到聊天记录判断电脑在线。离线期间是否补跑依实际纪录与产品行为确认，不假设会追补所有错过的时间。

CLI 脚本则先保存 status、stderr 与事件档，再在原终端机确认该程序是否已结束；需要中止时只针对已确认的工作，用 Ctrl+C 或该工具的取消入口，不终止所有 node、python 或 Codex 程序。GitHub Actions 到该 run 按取消后确认终止状态；停用 workflow 管的是之后的触发。若错误其实是需要互动授权、输入路径改名或 API 额度不足，延长 timeout 不会修好原因；分别回到权限、路径与帐号专篇。

本系列的 run_summary.py 使用 subprocess.run(timeout=120)。依 Python 官方说明，逾时时会终止并等待它直接启动的子程序，再抛出 TimeoutExpired；初始程序建立可能使等待超过指定秒数。这不代表孙程序、其他主机或已送出的外部请求全部停止。调查时分别列出直接程序状态与尚未确认的其他工作，保留原 timeout 记录。

步骤 4：重试同一需求，保留不同尝试

只有在原工作已停止或已确认不会造成重复副作用、原因已修正后，才决定是否重试。本篇的工作只读虚构资料，但仍使用新的 run-02 资料夹保存新结果。先记下同一 input revision 与新的 attempt；修正的是输入内容时要换 revision，不能把不同资料的答案混在同一版本下。如下纪录是范本，请填自己观察到的状态，不把 accepted 范例直接当实际结果。

# Recovery record
- Objective: summarize the fictional checklist
- Input revision: exec-practice-1
- Host and folder: fill in locally
- Original run and state: fill in
- Last observed action: fill in
- Cause and correction: fill in
- Retry output folder: run-02
- Exit status and event validation: fill in
- Manual counts: total 3, completed 1, pending 2
- Accepted result path: fill in only after verification
- Schedule state after practice: fill in

若要让下游采用结果，先完整核对新 run 的退出状态、事件、schema 与人工计数，再在纪录填入唯一 accepted result path。不要把每一次重试都当成要寄信、上传或扣款一次；外部动作需要接收服务提供的幂等键或明确去重策略，不能只靠模型答应不重复。本教材的目录拒绝覆写只能保护本机同名产物，不是跨主机锁，也不能保证外部服务只做一次。涉及写入的实际工作，先查已发生的副作用再补做。

停止与完成判断

演练结束保留成功原件与明确标记的失败副本，用原件重新验证一次即可，不必反复跑模型。若实际排程已启用，到 Scheduled 暂停并确认状态，再查看是否还有活动 run；需要恢复时修改同一项并核对下一次时间、时区、主机及通知条件。只在状态改变、完成或需要处理的失败时通知，避免每次空检查都寄出相同内容。完成标准是你能说清楚原工作状态、失败原因、修正、重试与采用哪份结果；官方功能查证、本机副本测试、主机离线实测与云端 CI 执行应各自记录。

返回 Codex 教学总目录

阅读完整文字说明

Three numbered stages: identify the starting point, perform the exercise, and verify the result. Original illustration, not a product screenshot.

• AI 工具
• 教程
• Codex