-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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(cloudformation): custom resource changes property casing (behind feature flag) #7034
fix(cloudformation): custom resource changes property casing (behind feature flag) #7034
Conversation
BREAKING CHANGE: Disable Custom Resource properties from being uppercased
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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.
Please update the "commit message" section to actually include a description of the commit and also follow the instructions from the contribution guide on how to describe breaking changes under feature flags in the commit message.
/** | ||
* If this is set, properties of a custom resource will not be uppercased. | ||
*/ | ||
export const DISABLE_CUSTOM_RESOURCE_UPPERCASE_PROPERTIES = '@aws-cdk/aws-cloudformation:disableCustomResourceUppercaseProperties'; |
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.
Add a _CONTEXT
suffix please
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.
On another thought: I don't think this can be introduced behind a feature flag because it will break any "legacy" custom resource that's used in the application...
Instead, let's just introduce this as a prop in CustomResource
. In 1.x we will have to keep the current behavior as the default, but we can change this in 2.x
@@ -160,11 +161,17 @@ export class CustomResource extends Resource { | |||
|
|||
const type = renderResourceType(props.resourceType); | |||
const providerConfig = props.provider.bind(this); | |||
|
|||
// change properties to upper case under a feature flag (since this is a breaking change). | |||
const properties = this.node.tryGetContext(cxapi.DISABLE_CUSTOM_RESOURCE_UPPERCASE_PROPERTIES) |
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.
Can't use a feature flag for this because it can break "legacy" constructs used in "new" applications.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
@eladb thanks for reviewing the pull request. 😄 Please could I ask you to expand on the "legacy" constructs issue? Wouldn't that statement hold true for any type related bugs (e.g. changing a default value)? I'm guessing this pull request isn't the first to find this sort of mistake and to try and revert it. How were those changes handled? I'm certainly willing to create another property, but I'd like to fully discount the feature flag approach before we do. Again, thanks for the time reviewing and commenting on the PR. Much appreciated. |
Let's say this is released. This means that any new app created with
We try not to use feature flags for this purpose. They are very risky. As you can see we have very few flags in the system, and we try to keep this to a minimum. |
Any updates? |
…source-uppercase-properties
…source-uppercase-properties
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thanks for your response. Whilst I still think a feature flag is the way to go, I'll create a seperate branch for creating a new property. |
Thanks. As I said, a feature flag can break new users that use old custom resources, so it’s not a viable approach. |
This commit folds the `CustomResource` and `NestedStack` types from `@aws-cdk/aws-cloudformation` into `@aws-cdk/core` in order to allow code in `core` and other lower layers to use capabilities such as nested stacks and custom resources. This comes at a minor sacrifice to API fidelity: the provider's service token is for custom resources is now passed as a simple `string` instead of a strongly typed `ICustomResourceProvider`. But this is negligible for this type of resource given the high involvement users require to use it anyway. Additionally, the `NestedStack` class accepts a `notificationArns` as a `string[]` instead of an `sns.ITopic[]`. In both cases the API in `@aws-cdk/aws-cloudformation` (which is considered a stable module) remains unchanged with a compatibility layer added. We took this opportunity to change the behavior of custom resources so that it won't pascal-case property names by default. This resolves #4896 and resolves #7035 and supersedes #7034. The API in the aws-cloudformation module are still supported for backwards compatibility but marked as deprecated.
This commit folds the `CustomResource` and `NestedStack` types from `@aws-cdk/aws-cloudformation` into `@aws-cdk/core` in order to allow code in `core` and other lower layers to use capabilities such as nested stacks and custom resources. This comes at a minor sacrifice to API fidelity: the provider's service token is for custom resources is now passed as a simple `string` instead of a strongly typed `ICustomResourceProvider`. But this is negligible for this type of resource given the high involvement users require to use it anyway. Additionally, the `NestedStack` class accepts a `notificationArns` as a `string[]` instead of an `sns.ITopic[]`. In both cases the API in `@aws-cdk/aws-cloudformation` (which is considered a stable module) remains unchanged with a compatibility layer added. We took this opportunity to change the behavior of custom resources so that it won't pascal-case property names by default. This resolves #4896 and resolves #7035 and supersedes #7034. The API in the aws-cloudformation module are still supported for backwards compatibility but marked as deprecated.
Addressed in #7736 |
This commit folds the `CustomResource` and `NestedStack` types from `@aws-cdk/aws-cloudformation` into `@aws-cdk/core` in order to allow code in `core` and other lower layers to use capabilities such as nested stacks and custom resources. This comes at a minor sacrifice to API fidelity: the provider's service token is for custom resources is now passed as a simple `string` instead of a strongly typed `ICustomResourceProvider`. But this is negligible for this type of resource given the high involvement users require to use it anyway. Additionally, the `NestedStack` class accepts a `notificationArns` as a `string[]` instead of an `sns.ITopic[]`. In both cases the API in `@aws-cdk/aws-cloudformation` (which is considered a stable module) remains unchanged with a compatibility layer added. We took this opportunity to change the behavior of custom resources so that it won't pascal-case property names by default. This resolves #4896 and resolves #7035 and supersedes #7034. The API in the aws-cloudformation module are still supported for backwards compatibility but marked as deprecated.
The CustomResource type is currently uppercasing the first letter in each prop.properties key. There is no requirement in CloudFormation for the first letter to be uppercased. The CloudFormation documentation for Custom Resources shows properties with lowercase keys.
Uppercasing the properties prevents the porting of existing custom resources to CDK. Even when code changes to the backing Lambda function are possible, simple object destructuring is not.
This pull requests disables the uppercasing of Custom Resource properties.
Commit Message
BREAKING CHANGE: Disable Custom Resource properties from being uppercased
Fixes #7035
End Commit Message
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license