fix(core): overrideLogicalId validation

[nmussy]

Issue # (if applicable)

Closes #29701

Reason for this change

Calling overrideLogicalId on a Construct with an invalid logical ID (docs) would not throw an error at synthesis time. CloudFormation would

Description of changes

• Validate overrideLogicalId (must not be empty, must not be over 255 characters, must match /^[A-Za-z0-9]+$/
• Document exceptions with @error JSDoc tags

Description of how you validated changes

I've added unit tests, integration tests should not be necessary

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.

[nmussy]

Exemption Request: This is just a synth time check, CloudFormation is already failing if unhappy with the logical ID

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

[TheRealAmazonKendra]

I'm hesitant to accept this but am open to conversation about it. If CloudFormation updates their requirements here, it would create more manual work on our end. Is the error message unclear enough at deploy time that this provides a major quality of life improvement for users?

[nmussy]

The CloudFormation deploy time message is absolutely clear about this issue, this is a duplicated synth time check

The main issue is the difference in how the CDK resolves regular construct generated logical IDs vs overrides. The IDs provided to the constructor are slugified, but not the overrides:

new cdk.CfnOutput(this, 'Invalid construct name', { 
  value: 'value', 
});

new cdk.CfnOutput(this, 'Output', { 
  value: 'value', 
}).overrideLogicalId('Another invalid construct name');

$ npm run cdk synth

Outputs:
  Invalidconstructname:
    Value: value
  Another invalid construct name:
    Value: value

I don't think changing this behavior to also slugify the override is warranted, to leave the escape hatch as is. Giving the user an early warning is probably best.

This PR would also prevent an issue like #29700 from reoccurring. An integration test would have caught it, but a unit test would have been sufficient with this change.

[aws-cdk-automation]

This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week.

[nmussy]

@TheRealAmazonKendra Bump

[aws-cdk-automation]

This PR has been deemed to be abandoned, and will be automatically closed. Please create a new PR for these changes if you think this decision has been made in error.

[nmussy]

@TheRealAmazonKendra Bunping again 😅

[GavinZZ]

LGTM, I'm also a fan of throwing error at synthesize time to save some user time and we can control the error msg on our side to make sure it's clear.

Dismissing stale reviews.

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

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

[aws-cdk-automation]

AWS CodeBuild CI Report

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

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

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

[jnawk]

How could this possibly be correct? CloudFormation doesn't define what constitutes a valid logical ID outside of the Resources section of a template - eg the conditions section allows logical IDs that are snake_case - See @mjgoble 's issue linked above for an example of why merging this PR was the WRONG thing to do.