Skip to content

feat(stepfunctions): support Map ItemProcessor#27913

Merged
mergify[bot] merged 5 commits intoaws:mainfrom
lpizzinidev:gh-27878
Dec 15, 2023
Merged

feat(stepfunctions): support Map ItemProcessor#27913
mergify[bot] merged 5 commits intoaws:mainfrom
lpizzinidev:gh-27878

Conversation

@lpizzinidev
Copy link
Copy Markdown
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
Copy Markdown
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!

map.itemProcessor(definition);
```

To define a distributed `Map` state use the configuration parameter.
Copy link
Copy Markdown
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


if (this.iteration === undefined) {
errors.push('Map state must have a non-empty iterator');
if (this.iteration === undefined && this.processor === undefined) {
Copy link
Copy Markdown
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)

*
* @deprecated - use `itemProcessor` instead.
*/
public iterator(iterator: IChainable): Map {
Copy link
Copy Markdown
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
Copy Markdown
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

if (!this.iteration) return undefined;
return {
Iterator: this.iteration.toGraphJson(),
Iterator: this.iteration?.toGraphJson(),
Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
@lpizzinidev lpizzinidev requested a review from kaizencc December 14, 2023 10:52
@mergify
Copy link
Copy Markdown
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
@mergify
Copy link
Copy Markdown
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
Copy Markdown
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
@mergify
Copy link
Copy Markdown
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