自動化の失敗、再試行、停止

Codex 学習目次に戻る

目標と準備

この段落の教材・資料: JSON／JSONL · 予約編

手順1：先に実行状態を識別する

予約には保存設定があり、各起動は別の run です。設定の一時停止は実行中 run の取消ではなく、予約削除は既存変更の復元ではありません。ローカルラッパーの timeout は待機上限、画面の offline は接続不能を示すだけで、遠隔や全子プロセスの停止を証明しません。タスク・予約名、ホスト、フォルダー、タイムゾーン、入力版、最後の開始時刻、実行番号を先に記録します。

古いファイルに成功回答が残る場合があり、存在だけでは成功ではありません。

手順2：回答はあるが完了証拠がない状態を再現する

成功 run-01 をファイル管理画面で recovery-running にコピーし、コピー status.json だけ下記に変えて正しい final.json・イベントは残します。これは明示した模擬中断で、実際の失敗記録を成功に見せかけて編集しません。Windows は PowerShell、macOS／Linux は端末で教材場所から verify-only を実行します。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 を再検証して合格へ戻し、3結果をコピー演習と明記します。実際のホスト停止やモデルタイムアウトを発生させた証拠ではありません。

手順3：実際のタイムアウト・切断に対応する

デスクトップ予約なら Scheduled の同じ項目を一時停止し、新しい起動を防いでから既存 run の活動を見ます。ホスト切断は電源・ネットワーク・アプリ・フォルダーを復旧し、重複予約を作る前に元タスクの最終操作と結果を確認します。各 OS で実ホストを調べ、携帯の履歴表示だけでオンラインとは判定しません。逃した回の補実行は実記録と製品挙動で確認し、全時刻が追補されると仮定しません。

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 を使います。同じ入力版と新 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・手計算を確認し、採用パスを1つ記録します。再試行ごとに送信・アップロード・課金を繰り返さず、外部操作はサービス対応の冪等キーや明確な重複除去が必要です。モデルの約束だけでは足りません。既存フォルダーの拒否はローカル保存の保護で、分散ロックや外部1回限り実行ではありません。実書込では既発生の副作用を調べて不足分を補います。

停止と完了判定

成功原本と明記した失敗コピーを残し、モデルを繰り返さず原本を1回再検証します。実予約が有効なら 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