概要
StepFunctionsからLambdaを実行(Invoke)させる処理を作成していました。
その中で、Lambdaが失敗した際に、エラー発生時の処理としてRetry処理をさせようとしたところ、意図通りにエラーをキャッチすることができず、手こずったことがありました。
問題
概要 に記載したStepFunctionsを運用している中で、実行させようとしたLambdaでタイムアウトエラーが発生するケースがありました。
ただし、設定したと思っていたエラーのキャッチが上手くいっておらず、結果としてLambdaの再試行がされない問題が発覚しました。
前提
Workflow Studioを使ってLambda: Invokeアクションを追加すると、デフォルトでエラー時に再試行する設定が追加されています。
ただし、デフォルトのエラー処理でキャッチできるのは、本記事作成時点だと、以下4種となっていました。
Lambda.ServiceExceptionLambda.AWSLambdaExceptionLambda.SdkClientExceptionLambda.TooManyRequestsException
調査
Lambdaでタイムアウトエラーが発生した場合のレスポンスを確認しました。
どうやら、Lambdaでタイムアウトエラー時にはLambda.Unknownとエラー名となるようです。
→ 前提 に記載したデフォルト設定のエラー処理には含まれていないので、キャッチできなかったようですね！
{
"cause": "The cause could not be determined because Lambda did not return an error type. Returned payload: {\"errorMessage\":\"XXXX\"}",
"error": "Lambda.Unknown",
"resource": "invoke",
"resourceType": "lambda"
}
対応
調査 に記載した、Lambda.Unknownもキャッチするエラーに設定追加しました。
Lambda内でタイムアウトエラーをワザと発生させて挙動を検証したところ、意図通りにエラーをキャッチ＆再試行してくれました！
悩んだ点
Workflow Studioからエラー設定を追加しようとしたところ、添付画像のようなサジェストがでます。
一見、States.XXXXから選択することができないと勘違いしましたが、直接Lambda.Unknownと入力することで難なく設定することができました。
蛇足
今回の対応に記載した設定以外にも、States.ALL、もしくはState.TaskFailedを設定することで、他のエラーパターンも含んで包括的にキャッチしてくれます。
それぞれがどのような挙動をするか理解した上で、利用想定に伴った設定をするのかの取捨選択するのが良さそうです。
まとめ
StepFunctionsから実行するLambdaがタイムアウトした際の、エラーキャッチ設定についてまとめさせていただきました。
Workflow Studioを活用した際のデフォルト設定がなまじ優秀なせいで、詳細まで確認することなく利用してしまっていました。
どんな優秀なサービス/機能も過信するのではなく、確認/理解することの重要性を再認識する良い機会でした。
また、StepFunctionsのエラー処理についての詳細は、以下AWS公式ドキュメントもご参照ください。
Discussion