Error Handling in Common Fallback state with JSONata Query Language #400
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
bfreiberg
suggested changes
Aug 22, 2025
| @@ -0,0 +1,116 @@ | |||
| { | |||
| "Comment": "StateMachine using JSONata QueryLanguage with common fallback state for multiple task states", | |||
There was a problem hiding this comment.
Suggested change
| "Comment": "StateMachine using JSONata QueryLanguage with common fallback state for multiple task states", | |
| "Comment": "State machine using JSONata query language with common fallback state for multiple task states", |
| "End": true | ||
| } | ||
| }, | ||
| "QueryLanguage": "JSONata" |
There was a problem hiding this comment.
move to top, just to be more visible
| @@ -0,0 +1,66 @@ | |||
| # Common Fallback State - JSONata | |||
There was a problem hiding this comment.
Would maybe "Shared Fallback State" be a better description?
| @@ -0,0 +1,69 @@ | |||
| { | |||
| "title": "Common Fallback State JSONata", | |||
There was a problem hiding this comment.
Use same title as in the README
| "introBox": { | ||
| "headline": "How it works", | ||
| "text": [ | ||
| "This example workflow illustrate practical solutions for fetching failed state name in JSONata StateMachine with common fallback state for multiple task states. AWS Step Functions users commonly seek to implement centralized error reporting within their workflows to avoid duplicating error handling logic across multiple states. While implementing a shared error reporting task is straightforward, a significant challenge arises: the error reporting task can access the error message from the failed state, but cannot inherently determine which specific state triggered the error. This limitation becomes particularly problematic in workflows containing numerous Lambda functions, as it complicates identifying the exact point of failure. Using JSONata as our query language, we demonstrate approach to overcome this limitation, enabling comprehensive error tracking while maintaining workflow efficiency." |
There was a problem hiding this comment.
This is a bit too verbose, condense and leave out filler words like "practical", "particular", "comprehensive" etc.
Make the same changes to the README
| "cleanup": { | ||
| "headline": "Cleanup", | ||
| "text": [ | ||
| "1. Delete the stack: <code>sam delete</code>." |
There was a problem hiding this comment.
Suggested change
| "1. Delete the stack: <code>sam delete</code>." | |
| "Delete the stack: <code>sam delete</code>." |
|
|
||
| The workflow doesn't require any input. By default, the third lambda function in "ThirdLambdaState" task state is programmed to fail. Thus, the workflow execution fails at this task state and transitions into "FallbackState" with input as "FailedStateName": "ThirdLambdaState". | ||
|
|
||
| The "ThirdLambdaFunction" is intentionally programmed to simulate the failure. |
There was a problem hiding this comment.
Add to paragraph above and then remove
|
|
||
| ## Testing | ||
|
|
||
| To test the workflow, simply start an execution of the state machine. This workflow doesn't require any input payload. Observe the execution once it has completed. |
There was a problem hiding this comment.
Please include a description of what the user should expect
|
|
||
| 1. Delete the stack | ||
| ```bash | ||
| aws cloudformation delete-stack --stack-name STACK_NAME |
There was a problem hiding this comment.
You deployed using SAM, why not use sam delete?
| aws cloudformation list-stacks --query "StackSummaries[?contains(StackName,'STACK_NAME')].StackStatus" | ||
| ``` | ||
| ---- | ||
| Copyright 2022 Amazon.com, Inc. or its affiliates. All Rights Reserved. |
There was a problem hiding this comment.
Suggested change
| Copyright 2022 Amazon.com, Inc. or its affiliates. All Rights Reserved. | |
| Copyright 2025 Amazon.com, Inc. or its affiliates. All Rights Reserved. |
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.
Issue #, if available:
Description of changes:
Adding a new workflow of JSONata type that demonstrates practical solutions for fetching failed state name in JSONata StateMachine with common fallback state for multiple task states. AWS Step Functions users commonly seek to implement centralized error reporting within their workflows to avoid duplicating error handling logic across multiple states. While implementing a shared error reporting task is straightforward, a significant challenge arises: the error reporting task can access the error message from the failed state, but cannot inherently determine which specific state triggered the error.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.