StepFunctions: Improvements to Timestamp Validation #12074
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
MEPalma
added
the
semver: minor
MEPalma
requested review from
joe4dev,
dominikschubert and
gregfurman
as code owners
LocalStack Community integration with Pro 2 files ± 0 2 suites ±0 34m 10s ⏱️ - 1h 16m 57s Results for commit a6f3688. ± Comparison against base commit 630b2a1. This pull request removes 2582 and adds 22 tests. Note that renamed tests count towards both.This pull request removes 243 skipped tests and adds 5 skipped tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
tiurin
approved these changes
Jan 20, 2025
.../localstack/services/stepfunctions/asl/component/state/state_wait/wait_function/timestamp.py
Outdated
Show resolved
Hide resolved
| @@ -60,31 +72,34 @@ def _create_failure_event(self, env: Environment, timestamp_str: str) -> Failure | |||
| event_details=EventDetails( | |||
| executionFailedEventDetails=ExecutionFailedEventDetails( | |||
| error=StatesErrorNameType.StatesRuntime.to_name(), | |||
| cause=f"The TimestampPath parameter does not reference a valid ISO-8601 extended offset date-time format string: {self.string.literal_value} == {timestamp_str}", | |||
| cause="The Timestamp parameter does not reference a valid ISO-8601 " | |||
| f"extended offset date-time format string: {self.string.literal_value} == {timestamp_str}", | |||
There was a problem hiding this comment.
question: why do we need to print both literal value of object property and timestamp_str parameter? Also, what == here means?
There was a problem hiding this comment.
This error message is composed in an effort to match AWS's error message in these circumstances (example).
The message lists how the expression provided for sampling the timestamp {self.string.literal_value} evaluates to the invalid timestamp value {timestamp_str}. The error message may look like this: The TimestampPath parameter does not reference a valid ISO-8601 extended offset date-time format string: $.TimestampValue == 2016-12-05 21:29:29Z"
tiurin
approved these changes
Jan 20, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
The Step Functions (SFN) v2 interpreter has certain limitations in validating timestamp strings for the Timestamp field. This field can be set statically using string literals or dynamically, such as via JSONata expressions. While validation exists for TimestampPath fields, similar logic was not applied to Timestamp fields. Consequently, some timestamps failed validation during state machine creation, as described in #11997.
These changes enhance the validation logic to ensure both statically provided and dynamically computed timestamp values are checked for proper format and a valid date. Additionally, a series of positive and negative test cases have been added to verify timestamp handling.
It is worth mentioning that dynamically computed invalid timestamps via JSONata expressions result in a generic execution failure rather than a new evaluation failure. This discrepancy is limited to the error type, while the failure description correctly conveys the issue. Improvements to this behaviour are planned as we introduce validation patterns for JSONata expression outcomes.
Changes
Timestamp*fields