Skip to content
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

feat(stepfunctions): support Map ItemProcessor #27913

Merged
merged 5 commits into from
Dec 15, 2023
Merged

Conversation

lpizzinidev
Copy link
Contributor

Adds support for Map's ItemProcessor required field and deprecates Iterator.

Closes #27878.


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

@aws-cdk-automation aws-cdk-automation requested a review from a team November 9, 2023 16:52
@github-actions github-actions bot added feature-request A feature should be added or improved. p2 distinguished-contributor [Pilot] contributed 50+ PRs to the CDK labels Nov 9, 2023
@aws-cdk-automation aws-cdk-automation added the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Nov 10, 2023
Copy link
Contributor

@kaizencc kaizencc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some preliminary thoughts @lpizzinidev, but thanks for getting this started!

```

To define a distributed `Map` state use the configuration parameter.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unclear to me what the "configuration parameter" is

@@ -194,8 +207,16 @@ export class Map extends State implements INextable {
protected validateState(): string[] {
const errors: string[] = [];

if (this.iteration === undefined) {
errors.push('Map state must have a non-empty iterator');
if (this.iteration === undefined && this.processor === undefined) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, this is fine, but why not if (!this.iteration && !this.processor)

@@ -162,13 +162,25 @@ export class Map extends State implements INextable {

/**
* Define iterator state machine in Map
*
* @deprecated - use `itemProcessor` instead.
*/
public iterator(iterator: IChainable): Map {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docstring should mention mutex with itemProcessor

/**
* Define item processor in Map
*/
public itemProcessor(processor: IChainable, config: ProcessorConfig = {}): Map {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docstring should mention mutex with iterator

return {
Iterator: this.iteration.toGraphJson(),
Iterator: this.iteration?.toGraphJson(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't need this ? right? typescript should know whats up based on line 430

return {
ItemProcessor: {
...this.renderProcessorConfig(),
...this.processor?.toGraphJson(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't TS know this.processor exists without the ??

/**
* Render ProcessorConfig in ASL JSON format
*/
private renderProcessorConfig(): any {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
private renderProcessorConfig(): any {
private renderProcessorConfig() {

any doesn't help much, i'd rather TS guses at the return type

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, I specified the return type as this is the approach used for the other rendering functions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair :). If there's a reason for it I can't think of one, but it's whatever either way.

@aws-cdk-automation aws-cdk-automation removed the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Dec 13, 2023
@mergify mergify bot dismissed kaizencc’s stale review December 14, 2023 09:39

Pull request has been modified.

@aws-cdk-automation aws-cdk-automation added the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Dec 14, 2023
Copy link
Contributor

mergify bot commented Dec 14, 2023

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@aws-cdk-automation aws-cdk-automation removed the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Dec 14, 2023
Copy link
Contributor

mergify bot commented Dec 14, 2023

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
  • Commit ID: 1eb9130
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify mergify bot merged commit ac41730 into aws:main Dec 15, 2023
9 checks passed
Copy link
Contributor

mergify bot commented Dec 15, 2023

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

mergify bot pushed a commit that referenced this pull request Jan 22, 2024
Adds support for Map's [ItemSelector](https://docs.aws.amazon.com/step-functions/latest/dg/input-output-itemselector.html) field and deprecates [parameters](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-asl-use-map-state-inline.html#map-state-inline-deprecated-fields).

With the release of Distributed Maps, AWS StepFunctions has released a few new fields, and deprecated two old ones for Map states. One of them was `Iterator` which was replaced with `ItemProcessor`, the other one is `Parameters` (replaced by `ItemSelector`). A similar PR was made to deprecate `Iterator` (#27913). While they are deprecated, these fields are still supported (PR reflects that)

`ItemProcessor` and `ItemSelector` are both fields that are supported in `DISTRIBUTED` and `INLINE` mode, hence why they were added to the existing Map construct

Closes #23265

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
mergify bot pushed a commit that referenced this pull request Jun 13, 2024
… executionType in the ProcessorConfig (#30301)

### Issue # (if applicable)

Closes #30194 

### Reason for this change
In #27913, the ItemProcessor was introduced for use with the Map Class. With the executionType in the ProcessorConfig, it was possible to specify the executionType for the Map.
On the other hand, in #28821, the DistributedMap Class was introduced. The mapExecutionType of the DistributedMap class always overwrites the executionType of the ProcessorConfig.
Therefore, when using the DistributedMap class, the implementation ignores the executionType of the ProcessorConfig. However, this behavior cannot be inferred from the documentation.

### Description of changes
* Added to the docs that when using the DistributedMap Class, the executionType in the ProcessorConfig is ignored.
* Also added a warning.


### Description of how you validated changes
Add unit tests and integ tests



### Checklist
- [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
sarangarav pushed a commit to sarangarav/aws-cdk that referenced this pull request Jun 21, 2024
… executionType in the ProcessorConfig (aws#30301)

### Issue # (if applicable)

Closes aws#30194 

### Reason for this change
In aws#27913, the ItemProcessor was introduced for use with the Map Class. With the executionType in the ProcessorConfig, it was possible to specify the executionType for the Map.
On the other hand, in aws#28821, the DistributedMap Class was introduced. The mapExecutionType of the DistributedMap class always overwrites the executionType of the ProcessorConfig.
Therefore, when using the DistributedMap class, the implementation ignores the executionType of the ProcessorConfig. However, this behavior cannot be inferred from the documentation.

### Description of changes
* Added to the docs that when using the DistributedMap Class, the executionType in the ProcessorConfig is ignored.
* Also added a warning.


### Description of how you validated changes
Add unit tests and integ tests



### Checklist
- [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
mazyu36 added a commit to mazyu36/aws-cdk that referenced this pull request Jun 22, 2024
… executionType in the ProcessorConfig (aws#30301)

### Issue # (if applicable)

Closes aws#30194 

### Reason for this change
In aws#27913, the ItemProcessor was introduced for use with the Map Class. With the executionType in the ProcessorConfig, it was possible to specify the executionType for the Map.
On the other hand, in aws#28821, the DistributedMap Class was introduced. The mapExecutionType of the DistributedMap class always overwrites the executionType of the ProcessorConfig.
Therefore, when using the DistributedMap class, the implementation ignores the executionType of the ProcessorConfig. However, this behavior cannot be inferred from the documentation.

### Description of changes
* Added to the docs that when using the DistributedMap Class, the executionType in the ProcessorConfig is ignored.
* Also added a warning.


### Description of how you validated changes
Add unit tests and integ tests



### Checklist
- [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
distinguished-contributor [Pilot] contributed 50+ PRs to the CDK feature-request A feature should be added or improved. p2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

aws-cdk-lib/aws-stepfunctions: AWS StepFunctions recommends using ItemProcessor vs Iterator
4 participants