Step FunctionsのcontextのEnteredTimeはミリ秒がコンマゼロだとコンマ以下が消える🫥
2024.10.にAWSサポートさんに問い合わせた情報です。
記載時点でJSONPath形式しかサポートされておらずだったのでその記法に準拠します。
まとめ🚀
- Step Functionsのcontextオブジェクトにはステート開始時刻
EnteredTimeがISO 8601で含まれる - ISO 8601 拡張形式に倣う（例. 2025-02-03T04:05:06.111Z）
- ミリ秒が0の場合 "2025-02-03T04:05:06.000Z" ではなく "2025-02-03T04:05:06Z" となる
EnteredTimeに限らないかもしれないので、parseなどの処理に使うときにはケアしよう⭐️
AWS StepFunctionsのcontextオブジェクト📝
Step Functionsでは並列処理や非同期処理などをワークフローで可視化しながら実装でき、重宝する方は多いと思います。
Step Functionsで時刻情報を用いたい場合には、ステート実行時刻を利用する方法が考えられます
ステート実行時刻はcontextオブジェクトに含まれており
"$$.State.EnteredTime" # JSONPath形式
"{% $states.context.EnteredTime %}" # JSONata形式だとこう書けるはず
として記述し扱えます。
ISO 8601形式🕓
時間を表すフォーマットとしてISO 8601はメジャー中のメジャーですね。
エポック秒を扱うこともあるもののAWSでの可読性の高い時刻表示はこれだと思います。
先述のStepFunctionsの"EnteredTime"もISO 8601 拡張形式に従います。
実装していたもの📦
私が実装を担当した機能ではStep Functionsのジョブ実行履歴をDynamoDB Tableに保存する必要があり、ステート実行時刻を update_at AttributeにUpdateItemする作りにしました。
update_atはStep Functions内から呼び出すLambda Functionで利用するパラメータでもあり、
Lambda内でparseなどして利用していました。
ある日、エラーが起こる⚠️
ある日、エラー通知が届きました。
内容的にはLambdaにて時刻のparseが失敗した。というものです。
"EnteredTime"のミリ秒レンジが省略されたことが原因でした。
期待） "2025-02-03T04:05:06.000Z"
実際） "2025-02-03T04:05:06Z"
AWSサポートさんへ問い合わせる💬
AWSに限らずISO 8601拡張形式では当たり前なのか調べてもよいソースが見つかりませんでした。
よって本件、ミリ秒レンジを省略することって普通なのか確認しました。
サポートさんからの回答は
「省略されるのは仕様になります。変更する予定はないです。」
ということでした。まあ確かに沢山の方が利用してますし変更とか急にできないですよね。
そのため、Lambda側のparse処理に修正を加える形で対応しました。
個人的には、ミリ秒を省略することにはメリットよりデメリットの方があるのではないかという考えは今もくすぶってます。。。😇
「ドキュメントに補足する等をご一考ください」とフィードバック的にお願いだけしておきました。
ちょっと図々しかったかもしれませんね。
振り返り✍️
いまだに省略されるのが一般なのか自分は答えを持っていません。
もしご存知の方がいらっしゃれば教えていただきたく存じます。
一旦は実装時のケア不足とも取れるので、良い経験になったと前向きに捉えています。
話がズレますが2024.12.頃よりStep FunctionsはJSONata形式に対応してます。
これにより ISO 8601 → エポック秒 の変換もLambdaなどを介さずに行えるようになりました。
Bedrockに関するテンプレートも公開されてますし、上手に活用したいですね。
Discussion