Skip to content
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.

Sign up for GitHub

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

Jump to bottom

custom resource provider: custom physical resource ID for failed events #5524

Open
eladb opened this issue Dec 23, 2019 · 1 comment
Open

custom resource provider: custom physical resource ID for failed events #5524

eladb opened this issue Dec 23, 2019 · 1 comment
Labels
@aws-cdk/custom-resources Related to AWS CDK Custom Resources effort/medium Medium work item – several days of effort feature-request A feature should be added or improved. needs-discussion This issue/PR requires more discussion with community. p2

Comments

@eladb
Copy link
Contributor

eladb commented Dec 23, 2019 •
edited
Loading

@aws-cdk/custom-resources.Provider currently does not support specifying a custom resource physical ID when the user handler fails. This is because failure is signalled through any unhandled exception of the user handler lambda function.

Please +1 this issue if this is something you need.

Use Case

Theoretically, it might be useful to be able to customize the physical resource ID for failures, but probably a very rare requirement. For example, if CREATE fails after only a portion of the resource has already been created, the provider might wish to clean up by handling the subsequent DELETE operation issued by CloudFormation with some specific resource ID.

The current implementation of the custom resource provider framework makes it impossible to specify the PhysicalResourceId when submitting a FAILED response. It defaults to the one passed in by CloudFormation, which is what you want in most cases.

For failed CREATE events, when there is no physical resource ID passed by CloudFormation, the framework uses a marker and automatically ignores the subsequent DELETE operation, which is mostly what people want. Otherwise, they have to special-case this DELETE.

Proposed Implementation

One way to support this is to allow attaching a PhysicalResourceId to the exception thrown, but this is language-specific and we need to investigate it a bit further.

This is a 🚀 Feature Request
@eladb eladb added feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels Dec 23, 2019
eladb pushed a commit that referenced this issue Dec 23, 2019
feat(custom-resources): ignore DELETE after failed CREATE
b685f00 
When a CREATE operation fails, CloudFormation will automatically issue a DELETE operation with the `PhysicalResourceId` submitted by the FAILED response. The provider framework currently does not support customizing the PhysicalResourceId of a failed response (as described in #5524), and therefore it makes more sense to have the framework simply ignore this DELETE operation. Otherwise, the user handler will need to special case this somehow, without proper signal.

The solution is to use a special marker for the physical resource ID when a CREATE fails, and recognize this marker in the subsequent DELETE.
@eladb eladb mentioned this issue Dec 23, 2019
Merged
@eladb eladb changed the title cr.Provider: customize physical resource ID for failed CREATE events custom resource provider: custom physical resource ID for failed events Dec 23, 2019
eladb pushed a commit that referenced this issue Dec 23, 2019
feat(custom-resources): ignore DELETE after failed CREATE
bc98784 
When a CREATE operation fails, CloudFormation will automatically issue a DELETE operation with the `PhysicalResourceId` submitted by the FAILED response. The provider framework currently does not support customizing the PhysicalResourceId of a failed response (as described in #5524), and therefore it makes more sense to have the framework simply ignore this DELETE operation. Otherwise, the user handler will need to special case this somehow, without proper signal.

The solution is to use a special marker for the physical resource ID when a CREATE fails, and recognize this marker in the subsequent DELETE.
mergify bot pushed a commit that referenced this issue Dec 23, 2019
@mergify
feat(custom-resources): ignore DELETE after failed CREATE (#5525)
9ab989e 
* feat(custom-resources): ignore DELETE after failed CREATE

When a CREATE operation fails, CloudFormation will automatically issue a DELETE operation with the `PhysicalResourceId` submitted by the FAILED response. The provider framework currently does not support customizing the PhysicalResourceId of a failed response (as described in #5524), and therefore it makes more sense to have the framework simply ignore this DELETE operation. Otherwise, the user handler will need to special case this somehow, without proper signal.

The solution is to use a special marker for the physical resource ID when a CREATE fails, and recognize this marker in the subsequent DELETE.

* chore(build): resolve eslint plugins relative to cdk-build-tools

plugins are installed centrally under cdk-build-tools and therefore resolution should happen against that module instead of the current module. otherwise, we get an error `ESLint couldn't find the plugin "eslint-plugin-node".`

* moved MISSING_MARKER to the last minute

* update expectations
@SomayaB SomayaB added @aws-cdk/custom-resources Related to AWS CDK Custom Resources and removed needs-triage This issue or PR still needs to be triaged. labels Dec 23, 2019
@SomayaB SomayaB added the needs-discussion This issue/PR requires more discussion with community. label Dec 23, 2019
eladb pushed a commit that referenced this issue Dec 24, 2019
feat(custom-resources): ignore DELETE after failed CREATE (#5525)
8a4b22d 
* feat(custom-resources): ignore DELETE after failed CREATE

When a CREATE operation fails, CloudFormation will automatically issue a DELETE operation with the `PhysicalResourceId` submitted by the FAILED response. The provider framework currently does not support customizing the PhysicalResourceId of a failed response (as described in #5524), and therefore it makes more sense to have the framework simply ignore this DELETE operation. Otherwise, the user handler will need to special case this somehow, without proper signal.

The solution is to use a special marker for the physical resource ID when a CREATE fails, and recognize this marker in the subsequent DELETE.

* chore(build): resolve eslint plugins relative to cdk-build-tools

plugins are installed centrally under cdk-build-tools and therefore resolution should happen against that module instead of the current module. otherwise, we get an error `ESLint couldn't find the plugin "eslint-plugin-node".`

* moved MISSING_MARKER to the last minute

* update expectations
@eladb eladb added the effort/medium Medium work item – several days of effort label Jan 23, 2020
@eladb eladb added the p2 label Aug 17, 2020
@eladb eladb assigned rix0rrr and unassigned eladb Aug 17, 2020
@rix0rrr rix0rrr removed their assignment Jun 3, 2021
@indrora
Copy link
Contributor

indrora commented Sep 19, 2023

Closing as this ticket is stale (over 9 months since last event or relates to the CDKv1).

If this is still a relevant request in the CDKv2, please open a new ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
@aws-cdk/custom-resources Related to AWS CDK Custom Resources effort/medium Medium work item – several days of effort feature-request A feature should be added or improved. needs-discussion This issue/PR requires more discussion with community. p2
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@indrora @rix0rrr @eladb @SomayaB