fix(stepfunctions-tasks): runtime language used to evaluate expressions is ignored#30302
fix(stepfunctions-tasks): runtime language used to evaluate expressions is ignored#30302mergify[bot] merged 6 commits intomainfrom
Conversation
Signed-off-by: Francis <colifran@amazon.com>
aws-cdk-automation
left a comment
There was a problem hiding this comment.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
aws-cdk-automation
left a comment
There was a problem hiding this comment.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.
Signed-off-by: Francis <colifran@amazon.com>
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
| new sfn.Wait(this, 'Wait', { | ||
| time: sfn.WaitTime.secondsPath('$.d'), | ||
| }), |
There was a problem hiding this comment.
is there a reason to add a wait? Just wondering since it will make the test slower
| import { Construct } from "constructs"; | ||
| import * as lambda from "../../../aws-lambda"; | ||
|
|
||
| export class EvalNodejsSingletonFunction extends lambda.SingletonFunction { |
There was a problem hiding this comment.
Just for my understanding, is this used in packages/@aws-cdk/custom-resource-handlers/test/custom-resources-framework/expected/singleton-function-eval-nodejs.ts? If not, what's the purpose of this?
There was a problem hiding this comment.
Yeah. It's just a template to use as "expected" to compare against a result in a unit test.
|
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). |
…ns is ignored (aws#30302) ### Reason for this change `EvaluateExpression` exposes a runtime property that can be used to configure the runtime language used to evaluate an expression. When the handler for this was migrated into the handler framework we hid the runtime property and didn't make it configurable. As a result, when the runtime property is specified as part of `EvaluateExpressionProps` it ends up being dropped in place of the code generated runtime. ### Description of changes Added a configurable runtime property to the generated `EvalNodejsSingletonFunctionProps` interface and set this property using runtime property on `EvaluateExpressionProps` if one was provided. Otherwise, the current node 18 default is used. ### Description of how you validated changes Unit test for codegen with eval-nodejs-provider. Integ test for default `EvaluateExpression` runtime (we already test a configurable runtime, unfortunately this was the same as the default so this bug was not caught). ### 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*
|
Comments on closed issues and PRs are hard for our team to see. If you need help, please open a new issue that references this one. |
Reason for this change
EvaluateExpressionexposes a runtime property that can be used to configure the runtime language used to evaluate an expression. When the handler for this was migrated into the handler framework we hid the runtime property and didn't make it configurable. As a result, when the runtime property is specified as part ofEvaluateExpressionPropsit ends up being dropped in place of the code generated runtime.Description of changes
Added a configurable runtime property to the generated
EvalNodejsSingletonFunctionPropsinterface and set this property using runtime property onEvaluateExpressionPropsif one was provided. Otherwise, the current node 18 default is used.Description of how you validated changes
Unit test for codegen with eval-nodejs-provider. Integ test for default
EvaluateExpressionruntime (we already test a configurable runtime, unfortunately this was the same as the default so this bug was not caught).Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license