-
Notifications
You must be signed in to change notification settings - Fork 4k
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(route53): timeouts due to delete-existing-record-set-handler's wait time #27068
fix(route53): timeouts due to delete-existing-record-set-handler's wait time #27068
Conversation
…onds to regression caused by AWS SDK V3 migration Regression introduced in 399b6bb
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.
@@ -46,7 +46,7 @@ export async function handler(event: AWSLambda.CloudFormationCustomResourceEvent | |||
}, | |||
}); | |||
|
|||
await waitUntilResourceRecordSetsChanged({ client: route53, maxWaitTime: 60 }, { Id: changeResourceRecordSets?.ChangeInfo?.Id }); | |||
await waitUntilResourceRecordSetsChanged({ client: route53, maxWaitTime: 1800 }, { Id: changeResourceRecordSets?.ChangeInfo?.Id }); |
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.
Should be max 900, better yet 890 (to give Lambda 10s to send a response), and should match the defined Timeout
of the Lambda function itself.
✅ 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 |
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). |
…it time (#27068) This PR updates the wait time of the `delete-existing-record-set-handler` from 60 to 1800 seconds. Commit 399b6bb upgraded the handler to use the AWS SDK V3 (was V2) and made the following change: ``` - await route53.waitFor('resourceRecordSetsChanged', { Id: changeResourceRecordSets.ChangeInfo.Id }).promise(); + await waitUntilResourceRecordSetsChanged({ client: route53, maxWaitTime: 60 }, { Id: changeResourceRecordSets?.ChangeInfo?.Id }) ``` The V2 `route53.waitFor` waits for 1800 seconds (see [reference](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Route53.html#waitFor-property)) > `Waits for the resourceRecordSetsChanged state by periodically calling the underlying [Route53.getChange()](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Route53.html#getChange-property) operation every 30 seconds (at most 60 times).` The new explicit configuration was set to 60 seconds which is too short and caused timeouts and failure in our cloudformation stacks Supersedes and closes #27060 Co-authored-by: Tom Roshko [[email protected]](mailto:[email protected]) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This PR updates the wait time of the
delete-existing-record-set-handler
from 60 to 1800 seconds.Commit 399b6bb upgraded the handler to use the AWS SDK V3 (was V2) and made the following change:
The V2
route53.waitFor
waits for 1800 seconds (see reference)The new explicit configuration was set to 60 seconds which is too short and caused timeouts and failure in our cloudformation stacks
Supersedes and closes #27060
Co-authored-by: Tom Roshko [email protected]
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license