-
Notifications
You must be signed in to change notification settings - Fork 4.4k
fix(elasticache-alpha): deployment fails when serverlessCacheName or userGroupId is not specified #36459
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
base: main
Are you sure you want to change the base?
Conversation
…userGroupId is not specified
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 review is outdated)
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
|
|
||||||||||||||
|
|
||||||||||||||
|
Exemption Request: Existing unit tests already cover auto-generated names, and the integration test validates the 40-character limit in the generated snapshot. |
Issue # (if applicable)
Closes #36458
Reason for this change
When deploying an ElastiCache
ServerlessCacheorUserGroupwithout explicitly specifying aserverlessCacheNameoruserGroupId, the auto-generated name can exceed AWS ElastiCache's 40-character limit, causing deployment failures.The current implementation uses
Names.uniqueId()which generates names without length constraints. With longer stack names or construct paths, the generated identifier exceeds the service's maximum allowed length.Description of changes
Replace the name generation logic with
Names.uniqueResourceName(this, { maxLength: 40 })to ensure generated names respect the AWS limit:Description of how you validated changes
Added integration test
integ.serverless-cache-auto-generate-name.tsthat creates aServerlessCacheandUserGroupwithout specifying names.Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license