症状

Podcastを記事に変換する自動パイプラインで、すでに処理を終えた回がもう一度走りうる状態になっていた。ローカルに前回の成果物が残っていると、別の実行がそれを「未完の作業」と誤認して再開してしまう。放っておくと、工程2以降の再実行・Driveへの再保存・X予約・完了通知まで全部が二重になる。

検証環境

OpenClawで運用しているPodcast→記事変換パイプライン。成果物の最終保存先はGoogle Drive。

原因候補と確認したこと

「二度目は何もしない」という判定自体は入れるつもりでいた。問題はその判定の根拠。手元に残っているファイルを見て判断すると、前回の中間生成物が「再開材料」に化ける。

試したこと・失敗した方法

失敗を踏んでからの修正ではなく、誤認の仕組みに気づいて先回りした改修。なのでこの段は短い。

実際の原因

再開判定の根拠がローカルの残骸で、最終保存先(Drive)側の状態を見ていなかったこと。

解決方法と解決確認

prepare 工程で、Drive上に処理済み成果物がある回を検出したらローカルの旧成果物を消去して already_processed を返し、後続工程を止める仕様へ改修。already_processed は正常終了扱いで、工程2以降・Drive再保存・X予約・完了通知は走らない。この挙動をワークフロー定義とチェックリストにも反映して、運用ルールとして確定した。

今回得たEXP

冪等性は「二度目は何もしない」と決めるだけでは足りない。「やらない」判定と同時に、作業ディレクトリの初期化=残骸の掃除までが設計に入る。そして判定の根拠は、手元のファイルではなく最終保存先側の状態に置く。

現場でいえば、片付けまでが作業。翌日の職人が昨日の資材を見て段取りを誤らないように、終わった作業の残骸は現場に置かない。