-
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
feat(scheduler): start and end time for schedule construct #28306
Conversation
…scheduler-time-frame
…scheduler-time-frame
…scheduler-time-frame
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.
Looks good overall 👍
I left some suggestions for minor improvements.
@@ -213,6 +233,8 @@ export class Schedule extends Resource implements ISchedule { | |||
return this.metricAll('InvocationsSentToDeadLetterCount_Truncated_MessageSizeExceeded', props); | |||
} | |||
|
|||
private static readonly ISO8601_REGEX = /^(-?(?:[1-9][0-9]*)?[0-9]{4})-(1[0-2]|0[1-9])-(3[01]|0[1-9]|[12][0-9])T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])\.[0-9]{3}(Z)?$/; |
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.
private static readonly ISO8601_REGEX = /^(-?(?:[1-9][0-9]*)?[0-9]{4})-(1[0-2]|0[1-9])-(3[01]|0[1-9]|[12][0-9])T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])\.[0-9]{3}(Z)?$/; | |
private static readonly ISO8601_REGEX = /^([0-2]\d{3})-(0[0-9]|1[0-2])-([0-2]\d|3[01])T([01]\d|2[0-4]):([0-5]\d):([0-6]\d)((\.\d{3})?)Z$/; |
A previous issue was caused by TransitionDate being formatted without the final Z
so a different regex may be better in this case.
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.
You are absolutely right.
I made some modifications from your suggestion because CFn throws the following error if it does not include milliseconds.
StartDate needs to follow the format yyyy-MM-ddTHH:mm:ss.SSSZ
private validateTimeFrame(startDate?: string, endDate?: string) { | ||
if (startDate && !Schedule.ISO8601_REGEX.test(startDate)) { | ||
throw new Error(`startDate needs to follow the format yyyy-MM-ddTHH:mm:ss.SSSZ but got ${startDate}`); |
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.
throw new Error(`startDate needs to follow the format yyyy-MM-ddTHH:mm:ss.SSSZ but got ${startDate}`); | |
throw new Error(`startDate must be in ISO 8601 format, got ${startDate}`); |
} | ||
if (endDate && !Schedule.ISO8601_REGEX.test(endDate)) { | ||
throw new Error(`endDate needs to follow the format yyyy-MM-ddTHH:mm:ss.SSSZ but got ${endDate}`); |
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.
throw new Error(`endDate needs to follow the format yyyy-MM-ddTHH:mm:ss.SSSZ but got ${endDate}`); | |
throw new Error(`endDate must be in ISO 8601 format, got ${endDate}`); |
const start = new Date(startDate); | ||
const end = new Date(endDate); | ||
|
||
if (end <= start) { | ||
throw new Error(`startDate must come before the endDate but got startDate: ${startDate}, endDate: ${endDate}`); | ||
} | ||
} |
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.
if (startDate && endDate) { | |
const start = new Date(startDate); | |
const end = new Date(endDate); | |
if (end <= start) { | |
throw new Error(`startDate must come before the endDate but got startDate: ${startDate}, endDate: ${endDate}`); | |
} | |
} | |
if (startDate && endDate && startDate > endDate) { | |
throw new Error(`startDate must preceed endDate, got startDate: ${startDate}, endDate: ${endDate}`); | |
} |
It should be fine to compare the strings directly given the format.
### Configuring a start and end time of the Schedule | ||
|
||
If you choose a recurring schedule, you can set the start and end time of the Schedule by specifying the startDate and endDate. | ||
These values must follow the format `yyyy-MM-ddTHH:mm:ss.SSSZ`. |
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.
These values must follow the format `yyyy-MM-ddTHH:mm:ss.SSSZ`. | |
These values must follow the ISO 8601 format (`yyyy-MM-ddTHH:mm:ss.SSSZ`). |
@lpizzinidev |
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.
Nice 👍
@@ -138,6 +138,21 @@ new Schedule(this, 'Schedule', { | |||
}); | |||
``` | |||
|
|||
### Configuring a start and end time of the Schedule | |||
|
|||
If you choose a recurring schedule, you can set the start and end time of the Schedule by specifying the startDate and endDate. |
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.
If you choose a recurring schedule, you can set the start and end time of the Schedule by specifying the startDate and endDate. | |
If you choose a recurring schedule, you can set the start and end time of the Schedule by specifying the `startDate` and `endDate`. |
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 would also prefer the props to be just named start
and end
, or startTime
/endTime
.
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.
In CFn, it is StartDate and EndDate, so I shortened it to start and end.
startDate: '2023-01-01T00:00:00.000Z', | ||
endDate: '2023-02-01T00:00:00.000Z', |
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 think we standardized on using the Date
type a while back. Similar to what we are doing here. We can then convert to whatever format scheduler expects.
How do you feel about that? I think that's the best course of action here as it allows for more types of inputs, but feel free to push back.
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.
Thanks for the comment!
Using the Date type to allow for a variety of user inputs is certainly appealing.
However, I have some reservations about it, primarily due to potential issues with timezones.
When we initialize a Date object with a string that lacks timezone specification(new Date("2022-08-04T15:19:46.125")
), the system's timezone is used by default.
For instance, if a local machine is set to Asia/Tokyo and the CI environment to UTC, the same time would be offset by 9 hours between these environments.
Since we are only dealing with ISO 8601 format and exclusively in UTC for this properties, using a string might be a safer option to avoid these timezone pitfalls.
By typing these values as string representation in the ISO 8601 format, we could mitigate these inconsistencies and ensure more predictable behavior across different environments.
This is just my personal opinion and I would love to get feedback from the CDK team.
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.
CFN accepts startDate
only in UTC time. I think when we do new Date().toISOString()
the Date is automatically converted to UTC time, specifically ISO 8601, which is what we want.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toISOString
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.
Yes, toISOString
method is used to convert to ISO 8601 format (with UTC timezone), but in the previous comment I was referring to the timezone at the initialization of the Date object.
However, I would like to change these properties to use Date type, since this problem does not occur if the user passes a string with timezone at initialization, and this is not a CDK problem but a JavaScript Date class specification problem.
Sorry for the confusion.
Pull request has been modified.
@kaizencc |
…scheduler-time-frame
@kaizencc |
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.
Lovely @sakurai-ryo, thanks for your contribution!
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). |
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). |
This PR added support for start and end time of the schedule.
Description
Currently, users cannot set a start time and an end time for the schedule.
A schedule without a start date will begin as soon as it is created and available, and without an end date, it will continue to invoke its target indefinitely.
With this feature, users can set the start and end dates of a schedule, allowing for more flexible schedule configurations.
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-scheduler-schedule.html#cfn-scheduler-schedule-startdate
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-scheduler-schedule.html#cfn-scheduler-schedule-enddate
In CloudFormation, users can use this feature as follows:
Major changes
add property to ScheduleProps interface
Added startDate and endDate properties, and typed these values as string based on the following PR comments.
#26819 (comment)
It is not necessary to specify both startDate and endDate, they can be set independently.
Validation is performed on the following points.
If a time before the current time is specified, the following error occurs in CFn, but no validation is performed because the timing of validation in CDK and the timing of actual deployment are different.
The StartDate you specify cannot be earlier than 5 minutes ago.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license