-
Notifications
You must be signed in to change notification settings - Fork 4k
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
refactor(stepfunctions-tasks): make integrationPattern an enum #3115
Conversation
Although I managed to run and test the module in my local, the automatic checks failed. The Travis CI build failure was caused by the fact that this code change does not guarantee backwards compatibility. Some boolean parameters have been removed and a new enum parameter has been added in place. Please let me know if I can do something to skip this. I look forward to your feedback. |
packages/@aws-cdk/aws-stepfunctions-tasks/lib/publish-to-topic.ts
Outdated
Show resolved
Hide resolved
packages/@aws-cdk/aws-stepfunctions-tasks/lib/publish-to-topic.ts
Outdated
Show resolved
Hide resolved
packages/@aws-cdk/aws-stepfunctions-tasks/lib/run-ecs-task-base.ts
Outdated
Show resolved
Hide resolved
/** | ||
* Call a service and have Step Functions wait for a job to complete. | ||
*/ | ||
RUN_A_JOB = '.sync', |
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.
I don't like very much that these enum values are used for computation. Please just use symbolic string names and add a lookup table to transform them into the appropriate suffixes.
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.
Also, are you sure RUN_A_JOB
conveys the synchronicity of the action clearly enough?
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.
I defined a map of <ServiceIntegrationPattern, string> to contain the suffix of each integration pattern.
Also, renamed RUN_A_JOB
as SYNC
.
/** | ||
* Call a service and let Step Functions progress to the next state immediately after it gets an HTTP response. | ||
*/ | ||
REQUEST_RESPONSE = '', |
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.
I know this is your terminology and so we should keep it, but this identifier is not at all clear to me.
The expected behavior is more akin to FIRE_AND_FORGET
, no? Or API_CALL_ONLY
? Can we do something about the docstring, maybe name it something like "[...] to the next state immediately after the API call completes" ?
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.
I renamed REQUEST_RESPONSE
as FIRE_AND_FORGET
and RUN_A_JOB
as SYNC
.
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.
For clarity, I'm not mandating: I'm only trying to engage you in discussion here. Since I believe "request response" is the terminology used in your official documentation, I'm not sure it's worth changing the term since it may confuse users.
If you as a service owner are okay with deviating from the terminology as a conscious choice, I would welcome the change. If the terminology should stay the same, I completely understand, but then we should make the behavior very clear in the doc string.
packages/@aws-cdk/aws-stepfunctions-tasks/lib/sagemaker-train-task.ts
Outdated
Show resolved
Hide resolved
packages/@aws-cdk/aws-stepfunctions-tasks/lib/sagemaker-transform-task.ts
Outdated
Show resolved
Hide resolved
@@ -57,6 +57,7 @@ test('Running a Fargate Task', () => { | |||
|
|||
// WHEN | |||
const runTask = new sfn.Task(stack, 'RunFargate', { task: new tasks.RunEcsFargateTask({ | |||
serviceIntegrationPattern: sfn.ServiceIntegrationPattern.RUN_A_JOB, |
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.
Does synchronous or asynchronous make more sense as a default? What are users most likely to want?
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.
Ready to ship this given:
- The lookup map is moved to the
-tasks
module. - You indicate you are comfortable with the FIRE_AND_FORGET rename.
WAIT_FOR_TASK_TOKEN = 'WAIT_FOR_TASK_TOKEN' | ||
} | ||
|
||
export const resourceArnSuffix = new Map<ServiceIntegrationPattern, string>(); |
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.
I'd rather this map lives in the aws-stepfunctions-tasks
library (NOT exported from index.ts
).
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.
Thank you for the quick reply. I will move this map to aws-stepfunctions-tasks
.
In the interest of expediency and also integrating the changes on the other PR, if I don't get to it anymore, anyone on Seattle time is free to merge this once the requested changes have been addressed. |
…erns for tasks Step Functions allows users to call different integrated services in different ways. They are also called service integration patterns, including Request Response, Run a Job and Wait for Callback. Users must choose exactly one of them and specify it in the "Resource" field. This commit introduces a new member variable, serviceIntegrationPattern, in the interface of properties within each existing integrated service. This helps to avoid using multiple boolean variables in the service such as ECS, which supports different service integration patterns. It is also beneficial for code maintenances: if Step Functions adds new integrated services or updates the existing integration patterns in the future, keeping pace with these changes will be simply updating this variable of enum type. BREAKING CHANGE: To define a callback task, users should specify "serviceIntegrationPattern: sfn.ServiceIntegrationPattern.WAIT_FOR_TASK_TOKEN" instead of "waitForTaskToken: true". For a sync task, users should use "serviceIntegrationPattern: sfn.ServiceIntegrationPattern.SYNC" in the place of "synchronous: true". In addition, this commit enables users to define callback task with ECS. **@aws-cdk/aws-stepfunctions-tasks** Closes aws#3114
*/ | ||
readonly waitForTaskToken?: boolean; | ||
readonly serviceIntegrationPattern?: sfn.ServiceIntegrationPattern; |
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.
Rename to integrationPattern
Step Functions allows users to call different integrated services in different, called service integration patterns. Instead of using booleans, this commit introduces a new property,
integrationPattern
, for all stepfunctions tasks which indicates the integration pattern (fire and forget, synchronous call, or wait for callback).BREAKING CHANGE: If you used to pass
waitForTaskToken: true
you now need to passintegrationPattern: sfn.ServiceIntegrationPattern.WAIT_FOR_CALLBACK
. If you used to passsync: true
, now passintegrationPattern: sfn.ServiceIntegrationPattern.SYNC
. In addition, this commit enables users to define callback task with ECS.Closes #3114
Please read the contribution guidelines and follow the pull-request checklist.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license