-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
fix(stepfunctions-tasks): runtime language used to evaluate expressions is ignored #30302
Conversation
Signed-off-by: Francis <colifran@amazon.com>
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.
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.
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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*
…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
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 ofEvaluateExpressionProps
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 onEvaluateExpressionProps
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
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license