ワークフローが2回動いたり、途中で失敗したりしたらどうなる？

再試行するには、すでに何が起きたかを知る必要があります。

お問い合わせが2回届くことがあります。人が2回承認することもあります。ワークフローの途中まで動いたところで接続が失敗することもあります。これらは別々の状況です。何かを繰り返す前に、依頼、意図した操作、その結果を示す記録を確かめてください。

サンプルは記録を残し、もう一度確認を求めます。

ブラウザーのデモでリセットし、「新しいご依頼」を実行します。「この承認で接続の失敗を試す」にチェックを入れ、「デモの返信を承認」を押します。「接続を一時停止中」とその履歴を確かめます。「例の接続を復旧」を選び、文章をもう一度確認して承認します。復元ボタンは失敗のチェックボックスを外すので、次の承認でサンプルを完了できます。

何が残り、何が繰り返されないのか？

足りない情報は、復元したあとも足りないままです。情報が足りないお問い合わせを復旧後に承認すると、「詳細を待っています」に戻ります。再試行しても、地域をつくり出したり、予約を確定したり、お客様の答えを受け取ったりはしません。

実際の途中での失敗は、もっと難しいものです。

つながったワークフローが案件の記録を更新したあと、成功をローカルに記録する前に確認の応答を失ったとします。送り先は変わっているのに、ローカルの状態ははっきりしないかもしれません。ワークフロー全体を繰り返すと、外部への影響も繰り返してしまうおそれがあります。

これは本番での仮定のケースで、Fireflax のサンプルでは模擬していません。実際に導入するには、依頼と意図した操作の消えない識別子、結果の記録の保存、送り先の確認、結果が不確かなときのルールが必要です。ブラウザーのメモリーと、メッセージの文章の一致だけでは足りません。

オフラインのスターターはローカルファイルを残し、明示的な一時停止のコマンドもありますが、あくまでひとつのプロセスでの練習です。同時の再試行が安全であること、確実に1回だけ届くこと、本番の稼働率、システムをまたいだ巻き戻しを示すものではありません。

このリカバリーのチェックリストを使いましょう。

1. 止めて、残す。 決めておいた手順で、関係するワークフローを止めます。依頼、バージョン、エラー、結果の記録を残します。
2. 送り先を確かめる。 メッセージ、記録、そのほかの意図した変更が実行されたかを確かめます。済み、未実行、不確かのどれかに分類します。
3. やみくもに再送しない。 不確かな点は、担当者とシステムの記録をもとに解決します。依頼と操作の識別子、重複のルールを確かめます。
4. 権限の管理者と一緒に復元する。 必要に応じて、実際の接続を直すか、あらためて認可します。アクセスを戻しても、すべての操作を再実行してよいことにはなりません。
5. もう一度確認する。 最新の依頼と、変わったやり取り、下書き、連絡方法の希望を確かめ直します。必要なところでは、あらためて承認を得ます。
6. 意図した結果をひとつ確かめる。 認められた次の操作だけを行い、その結果を確かめ、通常の作業に戻る前に何が起きたかを記録します。

これらの手順の担当者と代理を決めてください。すでに送ったメッセージは、社内の記録をリセットしても取り消せません。訂正や取り消しには、それぞれの権限と確認済みの限界が必要です。

記録を引き継ぎの資料のそばに置いておきましょう。

保存しているソースとスターターの実行は、それぞれ決めておいた5つのケースを扱い、承認の繰り返しや、承認の失敗と復旧も含みます。合成した入力、正確な状態、履歴を記録しています。別にある21個のリポジトリのテストでは、足りない情報からの復旧も確かめています。これらの限られたチェックは上の説明を裏づけるものであり、届くことを保証するものではありません。