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