Amazon Quick Flows が失敗したときのエラー通知メールの内容を確認してみた
はじめに
以前、Amazon Quick Flows でスケジュール実行中にステップ内でエラーが起きても、フロー全体が Failed 判定にならない件を記事にしました。
今回も引き続き安定動作確認のための試験運用中に別のパターンのエラーを確認しました。アクション確認を求めるパターンで、ワークフローのエラー自体はメール通知で気づけました。復旧後も最終的な通知先である Slack への通知は届かず、前回記事で取り上げた既知事象と同じ挙動でした。失敗時のメール内容と切り分けの流れをまとめます。
確認結果
- ユーザー確認が必要なアクションでエラーになるとエラー通知メールが届く
- メール内のリンクから詳細画面に遷移でき、状況確認がしやすい
- 今回の原因は「確認なしで実行」トグルが外れていたこと。トグルを戻すとエラー通知メールは止まった
- Slack 通知ステップの失敗は「正常終了メール」として届くため、メールだけでは気づけない。前回記事の既知事象の再現だった
エラー通知メールが届いた
ある日、以下のメール通知が届きました。
メール内のリンクを開くと、内容どおりアクションの確認が必要な状態でした。スケジュールで自動実行しているにもかかわらず、メール送信のアクション確認が求められていました。
Send messageをクリックしたところ正常に Slack へ通知されました。
手動実行では Slack 通知まで問題なく届く
まず切り分けのため、手動実行を試みました。
フローを選択して手動実行を開始します。
メッセージ上は正常に送信されています。Slack チャンネルへの通知も確認できました。
手動実行では Slack まで問題なく届くことが分かりました。スケジュール実行側に問題があると判断し、設定を確認します。
エラー通知メールの原因を確認する
スケジュール実行の設定を確認すると、確認なしで実行のトグルが外れていました。 トグルをオンに戻します。
トグルがいつ外れたかは特定できませんでした。スケジュール設定の変更画面を開いても、トグルが自動でオフに戻るわけではありませんでした。「ユーザーの確認が必要です」というエラーが出た場合は、このトグルの状態を確認してください。
スケジュール実行時間を直近に変更し待ったところ、正常終了のメールが届きました。
アクション確認を求めるエラーの原因はトグル設定だったと判断できました。
ただし、トグルを戻しても Slack 通知は届かない
正常終了メールは届いたものの、Slack への通知は来ていません。実行履歴を確認します。
Slack 通知ステップが失敗しているものの、フロー全体はエラー判定になっていません。前回記事で取り上げた既知事象と同じ振る舞いです。詳細は以下の記事を参照してください。
トグル修正後も手動実行では Slack 通知が届く
スケジュール設定を戻した後も手動実行では Slack 通知が届くかを確認しました。Slack インテグレーションの設定自体が原因ではなく、スケジュール実行経路だけの問題であることを切り分ける目的です。
手動実行します。
Slack への通知を確認します。
手動実行では Slack まで届きました。Slack インテグレーションの設定そのものは正しく機能しており、スケジュール実行経路からの Slack 通知失敗は私の環境で繰り返し発生している状況です。
まとめ
今回の事象を通じて分かったことを整理します。
- アクション確認型のエラーはメール通知で気づける。リンクから詳細画面へ遷移できるため、状況確認と対応が取りやすい
- 「確認なしで実行」のトグルが外れていると、スケジュール実行でもアクション確認が求められエラー扱いになる
- Slack 通知ステップの失敗は正常終了メールとして届くため、メール監視だけでは検知できない（前回記事の既知事象と同じ挙動）
おわりに
現時点ですと Quick Flows から Slack へ不定期に通知する場合、Slack 未達を検知する仕組みを別途用意しておくことになりそうです。定期通知であれば届かないことを契機に対応できますが、不定期だと困ります。
