It seems events.Schedule.expression passed as schedule for new events.Rule is not validated until deployment.
Expected Behavior
Having an invalid schedule expression is caught at synthesis time instead of producing a broken template.
Current Behavior
The stack synthesizes a broken CloudFormation template that fails to deploy.
Reproduction Steps
import cdk from "aws-cdk-lib"
import lambda from "aws-cdk-lib/aws-lambda"
import * as lambdaEventSources from 'aws-cdk-lib/aws-lambda-event-sources'
import * as targets from 'aws-cdk-lib/aws-events-targets'
import * as events from 'aws-cdk-lib/aws-events'
const methodProps = {
architecture: lambda.Architecture.ARM_64,
code: lambda.Code.fromAsset("./src/"), // Place some index.js file in src folder
functionName: "index",
handler: "index.handler",
layers: [],
memorySize: 1536,
runtime: lambda.Runtime.NODEJS_18_X,
timeout: cdk.Duration.minutes(10)
}
const handler = new lambda.Function(this, "index", methodProps)
const eventRule = new events.Rule(this, 'ScheduleRule', {
schedule: events.Schedule.expression('cron(0/10 * ? * *)') // Adding one * or such in the end will make this valid
})
eventRule.addTarget(new targets.LambdaFunction(handler))
Possible Solution
I saw another issue that mentioned the expression's purpose might be to allow using new patterns before they are added to e.g. Schedule.cron. So either this can be decided to be by design, in which case some extra note on the function that the deployment is validated at runtime instead of synthesis time could be added. Alternatively, if it is decided that a successful synthesis should produce a functioning template, some validation functionality for the expression is needed.
The validation and allowing a fallback could probably coexist: validate against currently known expressions, and create an option in e.g. cdk.json context to allow unvalidated, or give a prompt / warning etc. if an expression falls through validation without hitting anything.
Additional Information/Context
Use case here is using environment variable for the expression to allow development, staging, and production lambdas to run at different intervals e.g. more frequent during development vs less frequent in production.
This touches a little on issue 7514. They seemed to have the same missing final value and got the same error during deployment. They switched their approach as the error message did not make it clear why the expression failed (first used empty, then a rate).
Describe the bug
It seems events.Schedule.expression passed as schedule for new events.Rule is not validated until deployment.
Expected Behavior
Having an invalid schedule expression is caught at synthesis time instead of producing a broken template.
Current Behavior
The stack synthesizes a broken CloudFormation template that fails to deploy.
Reproduction Steps
Possible Solution
I saw another issue that mentioned the expression's purpose might be to allow using new patterns before they are added to e.g. Schedule.cron. So either this can be decided to be by design, in which case some extra note on the function that the deployment is validated at runtime instead of synthesis time could be added. Alternatively, if it is decided that a successful synthesis should produce a functioning template, some validation functionality for the expression is needed.
The validation and allowing a fallback could probably coexist: validate against currently known expressions, and create an option in e.g. cdk.json context to allow unvalidated, or give a prompt / warning etc. if an expression falls through validation without hitting anything.
Additional Information/Context
Use case here is using environment variable for the expression to allow development, staging, and production lambdas to run at different intervals e.g. more frequent during development vs less frequent in production.
CDK CLI Version
2.101.1 (build 16ddad1)
Framework Version
No response
Node.js Version
v18.18.2
OS
macOS 14.0
Language
TypeScript
Language Version
No response
Other information
This touches a little on issue 7514. They seemed to have the same missing final value and got the same error during deployment. They switched their approach as the error message did not make it clear why the expression failed (first used empty, then a rate).