fix(stepfunctions-tasks): fix bedrock input/output path in step-funct…#31305
fix(stepfunctions-tasks): fix bedrock input/output path in step-funct…#31305mergify[bot] merged 19 commits intomainfrom
Conversation
godwingrs22
left a comment
There was a problem hiding this comment.
Overall looks good. Just left few minor comments
packages/aws-cdk-lib/aws-stepfunctions-tasks/lib/bedrock/invoke-model.ts
Outdated
Show resolved
Hide resolved
packages/aws-cdk-lib/aws-stepfunctions-tasks/lib/bedrock/invoke-model.ts
Outdated
Show resolved
Hide resolved
packages/aws-cdk-lib/aws-stepfunctions-tasks/lib/bedrock/invoke-model.ts
Outdated
Show resolved
Hide resolved
packages/aws-cdk-lib/aws-stepfunctions-tasks/lib/bedrock/invoke-model.ts
Outdated
Show resolved
Hide resolved
packages/aws-cdk-lib/aws-stepfunctions-tasks/lib/bedrock/invoke-model.ts
Show resolved
Hide resolved
packages/aws-cdk-lib/aws-stepfunctions-tasks/lib/bedrock/invoke-model.ts
Outdated
Show resolved
Hide resolved
| InputPath: '$.prompt', | ||
| OutputPath: '$.prompt', |
There was a problem hiding this comment.
Are there other unit tests that test this functionality?
There was a problem hiding this comment.
There are two unit tests, one to check the expected template and one to check the permissions populated in policy
There was a problem hiding this comment.
The title of this unit test is "invoke model allows input and output json path". I think this test was originally meant to test the original behavior of inputPath and outputPath. So we need an additional new test for these new s3InputUri and s3OutputUri params, AND fix this unit test to go back to testing the original behavior of inputPath and outputPath.
There was a problem hiding this comment.
Update: I see in the history now that you had actually added this test in the last change. I do still think we should have both tests (inputPath and s3InputUri)
There was a problem hiding this comment.
Thanks @clareliguori , this leads to one question can body be skipped in case of an inputPath ? since the earlier validation seems to added only for body and input and didn't point to a definition where we might be using these base props.
There was a problem hiding this comment.
Oh I see, yes you still need body. With inputPath, you would do something like body=sfn.JsonPath.object_at("$")
There was a problem hiding this comment.
Yeah seems like I totally missed adding unit tests for inputPath and outputPath
| body: sfn.TaskInput.fromObject( | ||
| { | ||
| inputText: sfn.JsonPath.format( | ||
| 'Alphabetize this list of first names:\n{}', | ||
| sfn.JsonPath.stringAt('$.names'), | ||
| ), | ||
| textGenerationConfig: { | ||
| maxTokenCount: 100, | ||
| temperature: 1, | ||
| }, | ||
| }, | ||
| ), | ||
| outputPath: sfn.JsonPath.stringAt('$.names'), |
There was a problem hiding this comment.
Can help me to understand why body is required instead of inputPath?
There was a problem hiding this comment.
just added this integ test is to make sure, we are not breaking any existing use case for outputPath or inputPath from the base class, looking back at why it might have been marked as required could be a decision taken while designing this s3 input parameter, i don't see it something as required in API doc
There was a problem hiding this comment.
In order to test the inputPath field, you can do a Pass state to transform the previous output into the format expected for the InvokeModel body.
| /** Test for Bedrock s3 URI Path */ | ||
| const prompt4 = new BedrockInvokeModel(stack, 'Prompt4', { | ||
| model, | ||
| s3InputUri: sfn.JsonPath.stringAt('$.names'), | ||
| s3OutputUri: sfn.JsonPath.stringAt('$.names'), | ||
| }); | ||
|
|
There was a problem hiding this comment.
Can you run the verification steps listed at the top of this class?
Stack verification steps
df27bb4 to
9a4b791
Compare
packages/aws-cdk-lib/aws-stepfunctions-tasks/lib/bedrock/invoke-model.ts
Outdated
Show resolved
Hide resolved
79dec88 to
47d60bd
Compare
| postCliContext: { | ||
| '@aws-cdk/aws-cdk.aws-stepfunctions-tasks:useNewS3UriParametersForBedrockInvokeModelTask': true, | ||
| }, |
There was a problem hiding this comment.
if the default value of the flag is True, so we do not need to set this flag, and instead you need to update the old integration test cases to set the flag to false to test the current behaviour (using Input path, and output path instead of the new S3 uris)
aa8897c to
a52bdcf
Compare
|
@Mergifyio update |
✅ Branch has been successfully updated |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
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). |
|
Comments on closed issues and PRs are hard for our team to see. |
Issue # (if applicable)
Closes #31302.
Reason for this change
PR#30298 introduced a breaking change in the stepfunctions-tasks which was encoding the input/output path from the
TaskStateBasePropsto be used to input a S3 URI, which is not always the case and customer might be using the JSON string as it is.Description of changes
To keep the functionality from the original ask of issue #29229 ,added another props to specify S3 URI as an input to the stepfunctions-tasks.
Introduced a feature flag to keep the existing behaviour for the customers and not introduce a breaking change.
Description of how you validated changes
Updated integ test and deployed in account
Integ Test Results:
aws stepfunctions start-execution --state-machine-arn <deployed state machine arn>: should return execution arnA5-zEnXPmmPWTJx
{
"executionArn": "arn:aws:states:us-east-1:XXXX:execution:StateMachine2E01A3A5-zEnXPmmPWTJx:516f2e60-9507-46cb-95e6-4d9453429b08",
"startDate": "2024-09-04T15:43:33.200000-07:00"
}
aws stepfunctions describe-execution --execution-arn <exection-arn generated before>: should return status as SUCCEEDEDChecklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license