MakeのIncomplete executionsが残ったら、最初に「どのmoduleで、どの入力を使い、どこまで外部処理が済んだか」を確認します。通常のscenarioを修正しただけでは、過去の未完了実行が新しい設定で再試行されるとは限りません。保存された未完了実行の内容と、現在のscenarioを分けて見ます。
この記事は既存の未完了実行を診断し、再試行かmanual Resolveかを選ぶ手順です。Makeのscenario作成・起動、接続の再認証、未完了実行の再試行・削除、外部サービスへの送信は実施していません。台帳は架空例で、実製品の復旧成功を示すものではありません。
目次
未完了実行のIDと保存された入力を確認する
Make公式のIncomplete executions説明（新しいタブで開く）は、保存を有効にしたscenarioで失敗した未完了runを保管すると説明しています。保存は既定で無効であり、履歴に失敗があるだけでは未完了実行も保存されているとは判断しません。
対象scenarioのIncomplete executionsから該当IDを開き、作成時刻、原因module、error、入力bundleを確認します。接続先や顧客情報を含む場合は、確認に必要な範囲だけを閲覧し、本文全文を別logへコピーしません。似た時刻の別runや、すでに手動で処理済みの入力と混同しないよう、業務上の対象IDも対応付けます。
表は横にスクロールできます
| 記録するもの | 確認する目的 | 未確認なら |
|---|---|---|
| 未完了実行ID | 再開対象を固定 | 一括再試行をしない |
| 原因moduleとerror | 一時障害か設定不備か分類 | 元の実行logを開く |
| 保存されたinput | 元データと対象を確認 | 想像で値を補わない |
| 先行処理の完了 | 重複する外部操作を探す | 接続先の現在状態を照合 |
status・attempts・予定時刻 | 自動再試行との競合を避ける | 進行中の処理を確認 |
元入力に間違いがあった場合、今のsourceが正しくなっているだけでは、保存された入力も更新済みとは言えません。
状態を原因ではなく処理状態として読む
未完了実行の管理資料（新しいタブで開く）には、Unresolved、Pending、In progress、Resolvedの状態が案内されています。Pendingは再試行待ち、In progressは実行中です。Unresolvedが残っていることを、常に現在のscenario全体が停止している証拠にはしません。通常実行と未完了queueを分けて確認します。
自動再試行の予定がある状態へ手動の再開を重ねる前に、実行中の処理と対象IDを確認します。待機時間は外部サービスの回復だけでなく、Make側の再試行 schedulingや同じscenarioの実行状態にも影響されます。表示時刻を過ぎたという理由だけで、同じ入力を別scenarioへ複製しません。
一時的な障害なら、元設定での再試行が妥当か判断する
公式の自動再試行説明（新しいタブで開く）は、RateLimitError、ConnectionError、ModuleTimeoutErrorや、所定の設定を持つRetry error handlerの未完了実行を対象として案内しています。すべてのerrorが自動で直る仕組みではありません。
通常の再試行は、errorが起きたmoduleから、失敗時のconfigurationを使って再開します。外部サービスの一時停止が解消し、元の設定と入力が今も正しいなら候補になります。接続先fieldやmappingが変わった場合は、同じ設定をもう一度使うだけでは原因が残る可能性があります。
表は横にスクロールできます
| 原因の想定 | 選ぶ方向 | 先に確認するもの |
|---|---|---|
| 一時的な接続停止 | 再試行の候補 | 接続先回復と二重処理 |
| rate limit | 予定・送信量を確認して再試行 | 同じ接続を使う他の実行 |
| field・mapping不備 | manual Resolveで修正 | 保存されたblueprintとinput |
| 入力の業務条件が不明 | 担当者へ確認 | 再開すべき対象か |
| 外部送信結果が不明 | 接続先を照合 | 未送信と決めつけない |
再試行にscenarioのactive状態が必要な場合も、単にtoggleを入れて終わりにしません。通常scheduleの再開が別の入力も動かすため、運用上の影響を確認します。本稿でactive化や送信を実行したという意味ではありません。
設定修正が必要なら、該当未完了実行を開いてResolveする
公式手順では、履歴またはIncomplete executionsからDetailsを開き、原因moduleを確認して修正・保存し、Run onceで再開します。現在の通常scenarioで設定を直したことと、この保存済み未完了実行を直したことを別に記録します。
manual Resolveも、元のinputを使って失敗moduleから再開する処理です。最新のsourceを最初から読み直す代用だと思い込まないでください。元入力がすでに処理済みか、古い状態を外部へ上書きしないかを確認します。必要な値の根拠がなければ、適当なdefaultを入れて通さず、対象を保留します。
失敗moduleの外部状態を照合する
前段moduleが完了しているなら、最初から通常scenarioを回すと、済んだ作成や通知を再実行する恐れがあります。さらに、失敗module自体が外部への書込後にtimeoutした場合、そのmoduleの再実行でも重複し得ます。「error表示があるから何も反映されていない」とは扱いません。
架空例として、請求メモを作成した後に応答を失った場合、元入力の業務IDで既存メモを探し、同じ内容が反映済みかを確認します。idempotency keyやrecord IDの扱いは接続先ごとに異なります。MakeのResolved状態だけで、外部のすべての操作が一度だけ実行されたと保証しません。
一件の復旧を確かめてから対象を広げる
まず原因が分かり、再開すべき一件に絞ります。errorが消えたかだけでなく、残りのrouteが期待どおり終わり、保存先の対象IDと内容が一致し、通知などの副作用が重複していないかを確認します。別moduleで失敗すると新しい未完了実行ができる場合があるため、元IDの状態と新IDの有無を追います。
未完了実行を一覧から消すためだけにDeleteを使わないでください。公式資料は削除した未完了実行を戻せないと説明しています。残りの処理が不要と確認された場合でも、業務上の扱い、保存データ、必要な記録を別に判断します。
完了記録には、原因、再開に使った設定と入力、再試行回数、外部状態の照合、残った未完了IDを残します。保存容量や上限も運用条件として確認し、未完了をためれば必ず復旧できると考えず、通常scenario側の再発防止も別に行います。