core: missing logical ID override validation

[nmussy]

Describe the bug

There is currently no validation made when a logical ID is overridden, despite it requiring to be alphanumeric (docs):

aws-cdk/packages/aws-cdk-lib/core/lib/cfn-element.ts

Lines 85 to 92 in 36fd79d

	public overrideLogicalId(newLogicalId: string) {
	if (this._logicalIdLocked) {
	throw new Error(`The logicalId for resource at path ${Node.of(this).path} has been locked and cannot be overridden\n` +
	'Make sure you are calling "overrideLogicalId" before Stack.exportValue');
	} else {
	this._logicalIdOverride = newLogicalId;
	}
	}

A RegExp match would have caught #29700

Expected Behavior

The logical ID should be matched against /^[A-Za-z0-9]+$/, and an error should be thrown if it doesn't

Current Behavior

No runtime check is made, and an error is thrown by CloudFormation at deploy time, such as:

Deployment failed: Error [ValidationError]: Template format error: Outputs name 'AssertionResultsHttpApiCallhttpbin.org/get0f06632dfa7261b35a1569da58f981ba' is non alphanumeric.

Reproduction Steps

import { App, CfnOutput, Stack } from "aws-cdk-lib";

const app = new App();
const stack = new Stack(app, 'TestStack', {});

new CfnOutput(stack, 'ValidName', { value: 'value' }).overrideLogicalId('Invalid/Name');

$ npm run cdk synth
Outputs:
  Invalid/Name:
    Value: value

$ npm run cdk deploy

 ❌  TestStack failed: Error [ValidationError]: Template format error: Outputs name 'Invalid/Name' is non alphanumeric.
Template format error: Outputs name 'Invalid/Name' is non alphanumeric.

Possible Solution

I think throwing an error here is the most sensible solution. Silently removing invalid characters for a manual override doesn't seem like a safe compromise, we need to warn the user (or CDK contributors) about this issue

Additional Information/Context

No response

CDK CLI Version

2.135.0

Framework Version

No response

Node.js Version

v20.11.1

OS

macOS 14.4.1

Language

TypeScript

Language Version

5.4.3

Other information

No response

[tim-finnigan]

Thanks for creating this issue! I think throwing an error for invalid input here makes sense as well.