fix(ec2): instance resourceSignalTimeout overwrites initOptions.timeout

[michelle-wangg]

Issue # (if applicable)

Closes #30052

Reason for this change

When specifiying both resourceSignalTimeout and initOptions.timeout in the options for creating an EC2 Instance, only the value from resourceSignalTimeout is used.

Description of changes

• If both initOptions.timeout and resourceSignalTimeout are set, timeout consisting of the sum of the values and a warning suggesting that only one field should be specified
• Else, timeout is set to field specified, else defaults to 5 min

Description of how you validated changes

• Update integration test for instance-init.js with both fields and verify that warning is logged
• Add unit tests:
  • initOptions.timeout and resourceSignalTimeout are both not set, timeout is set to default of 5 min
  • initOptions.timeout set and resourceSignalTimeout not set, timeout is set to initOptions.timeout
  • initOptions.timeout not set and resourceSignalTimeout is set, timeout is set to resourceSignalTimeout
  • initOptions.timeout and resourceSignalTimeout are both set, timeout is set to sum of timeouts and warning is logged

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

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.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[GavinZZ]

Nice Michelle! Left some comments.

I see your fix would now be summing the two values up. This would mean that users (who haven't changed their template) would have the values updated in their next deployment if they upgrade their CDK version. This is generally a sign of breaking change, however, in this case it's extending the timeout value. I think this can be argued to be a non-breaking change. Can you include @moelasmar in the review and get his though?

[moelasmar]

left minor comments, and you need to rerun the integration test cases with --update-on-failed flag

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: dab5af4
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[GavinZZ]

@mergify update

[mergify]

update

☑️ Nothing to do

• #commits-behind > 0 [📌 update requirement]
• -closed [📌 update requirement]
• -conflict [📌 update requirement]
• queue-position = -1 [📌 update requirement]

Dismissing Mohamed's review since it's all addressed.

[mergify]

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).

[github-actions]

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.