-
Notifications
You must be signed in to change notification settings - Fork 101
feat: add timezone support to scheduling for Lambda functions #3016
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
Conversation
🦋 Changeset detectedLatest commit: 2debf5a The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
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 contribution, added some comments.
} else if ('cron' in schedule) { | ||
return { ...schedule, timezone: schedule.timezone ?? DEFAULT_TIMEZONE }; | ||
} | ||
throw new Error("Could not determine the function's schedule type"); |
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.
This Error is not tested, can you include a test that covers it?
}); | ||
}); | ||
|
||
void it('sets valid schedule - rate with timezone', () => { |
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.
Could you add some test cases for invalid inputs for rate and timezone (invalid timezone)?
One of our workflows is failing because the changeset bumps |
@@ -0,0 +1,5 @@ | |||
--- | |||
'@aws-amplify/backend-function': minor |
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.
Need to bump @aws-amplify/backend
too.
@iankhou |
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.
One thing, we should use TimeZone
instead of string timezones, unless there is a very good reason not to.
CronOptionsWithTimezone, | ||
ScheduleExpression, | ||
} from 'aws-cdk-lib/aws-scheduler'; | ||
import { TimeZone } from 'aws-cdk-lib'; |
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 see we are importing TimeZone
here, why do we use string timezones in the rest of the changes?
return { minute: `*/${value}` }; | ||
return { | ||
minute: `*/${value}`, | ||
timeZone: TimeZone.of(schedule.timezone), |
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.
Why not pass a TimeZone
directly instead of making this conversion?
timezone: string; | ||
}; | ||
|
||
// @public (undocumented) | ||
export type ZonedTimeInterval = { | ||
rate: TimeIntervalExpression; | ||
timezone: string; |
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.
Same as comments above - TimeZone
@iankhou |
Not sure if that is intentional. I will consult with the team and get back to you soon. Some additional info - Did some research on this implementation and came away with the following findings: Case 1: Your approach of:
fails an SDK call at deploy time when the timezone is invalid - which is good. Case 2: An alternate approach of:
does not fail deployment, and defaults to UTC I had been worried that your implementation may fall victim to Case 2, but it does not. Still, would be best if we catch problems with the timezone at compile time. |
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 like we do have the precedence of using strings for these props.
Using strings instead of CDK types here makes configuration easier in some cases. I will approve this PR as-is.
Thanks @ShadowCat567 for confirming this, and thank you for your patience!
@iankhou Thank you for your prompt and polite response. |
Problem
Function schedules are powered by Amazon EventBridge rules, so not supported timezone.
Migrate EventBridge Scheduler to support timezone.
Issue number, if available:
fix #3008
Changes
Added a function schedule format that specifies the timezone.
We migrated from EventBridge rules to EventBridge Scheduler to support time zones.
Corresponding docs PR, if applicable:
aws-amplify/docs#8448
Validation
Checklist
run-e2e
label set.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.