-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Amazon States Language "ResultSelector" in Task, Map … #102
Conversation
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
…and Parallel States.
Any update with this? Would be fantastic to have! 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice work @yoodan93 !!
overall approach looks good. had some minor/naive questions.
I do think we can raise the bar on testing a bit more though
Taking over to help merge @yoodan93 's PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you also add some details around testing - i.e.
- have we tried generating a workflow and executing the state machine successfully?
at some point we should probably add some basic integ tests that exercise state machines and their support for ASL features. Presumably, we'll be adding more capabilities in the future. Probably not in scope for this PR, but worth thinking about sooner than later.
Added manual test details
Agreed! let's do add integ tests in another PR |
Requested changes have been addressed in the last commits
This is very unspecific. Can you share the SDK code you used to generate that? |
@@ -98,6 +99,7 @@ def __init__(self, state_id, wait_for_completion=True, **kwargs): | |||
comment (str, optional): Human-readable comment or description. (default: None) | |||
input_path (str, optional): Path applied to the state’s raw input to select some or all of it; that selection is used by the state. (default: '$') | |||
parameters (dict, optional): The value of this field becomes the effective input for the state. | |||
result_selector (dict, optional): The value of this field becomes the effective result of the state. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maintaining these docstrings for every inheriting class is pretty annoying. I wonder if there anything we can do to make that easier.
@@ -82,11 +105,23 @@ that returns the placeholder output for that step. | |||
definition = Chain([lambda_state_first, lambda_state_second]) | |||
|
|||
|
|||
Step Result | |||
----------- | |||
The third mechanism is a placeholder for a step's result. The result of a step can be modified |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still wondering if it's really necessary to introduce StepResult when StepInput could also be used to achieve the same thing. I left that comment earlier but it didn't get an answer. Literally the only difference is the class name. Thoughts @shivlaks?
We can always add classes later, but removing it afterwards breaks back-compat.
lambda_result = StepInput(
schema={
"Id": str,
}
)
lambda_state_first = LambdaStep(
state_id="MyFirstLambdaStep",
result_selector={
"Output": lambda_result["Id"],
"Status": "Success"
}
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question - I missed that comment earlier
While it does make sense to use the same object, I think the name StepInput
could bring confusion since, in this case, we are not using the step's input, but the step's result (or output)
To be backwards compatible, we can't rename StepInput
to a more general term. Alternatively, we could make StepResult
inherit from StepInput
instead of Placeholder
and avoid code duplication.
Agreed - this is not sufficient information to reproduce the test. I provided more details in the Testing section of the PR description |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Hi! Any plans on merging this PR soon? I'm writing a stepfunction state machine which requires this... Thanks. |
Add ResultSelector support for Task, Map and Parallel states.
Issue #, if available:
#95
Description of changes
Adding new Amazon States Language payload template "ResultSelector" https://states-language.net/#payload-template
This change allows user to define a
result_selector
which is used to define the effective result of a state.Testing
Workflow definition:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.