自動化失敗、重試與停止

返回 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