custom-resources: Configurable physical resource IDs on create failure

[athewsey]

Describe the feature

Today, when a custom resource managed by aws_cdk.custom_resources.Provider fails to create, the expected pattern seems to be for the user-provided onEvent handler to throw an error and the framework to return a dummy physical resource ID - as shown by this in the logs:

[provider-framework] CREATE failed, responding with a marker physical resource id so that the subsequent DELETE will be ignored

It would be great if there's an alternative way to fail creation but actually specify the PhysicalResourceId, so that during rollback a custom handler can see the physical ID of the part-created resource and clean up properly.

Use Case

I'm migrating SAM-based custom resources into CDK, which manage underlying AWS resources (like SageMaker Studio Domains & Amazon Kendra indexes) that get assigned a unique physical ID on creation that's not predictable from the input arguments.

My Custom Resource does some additional pre- and post-processing around the core AWS resource (otherwise I'd just be using direct constructs...), so it's possible for creation to fail after creating an underlying AWS resource.

As I understand, the standard CloudFormation paradigm for this case is that part-created resources are left as-is, and then the DELETE request issued on rollback should trigger clean-up. For CRs that map pretty closely to one particular AWS Resource, our old SAM-based CRs used the underlying resource ID (e.g. SageMaker Studio Domain ID, Kendra Index ID, etc) as the CR PhysicalResourceId. In vanilla CF / SAM, the handler for the DELETE request issued by stack rollback would have visibility of the PhysicalResourceId returned by the (failed) creation

I'd like my custom resource to clean up these partial items during stack rollback, and (for CRs that map pretty closely to one particular AWS Resource) use that underlying resource ID (e.g. SageMaker Studio Domain ID, Kendra Index ID, etc) as the physical resource ID of the CR.

Proposed Solution

Today, provider framework.ts hard-codes 'SUCCESS' in the CloudFormation result unless the user's Lambda function throws an error.

Instead, we could allow user Lambda responses to override this to 'FAILED' but still return whatever PhysicalResourceId and data were in their payload: Giving user Lambdas which are able to catch and properly handle failures a non-breaking ability to take advantage of this feature.

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.126.0

Environment details (OS name and version, etc.)

macOS Sonoma

[pahud]

Sounds like you have a CR that could not properly clean up created resources on DELETE signal? Can you share a very tiny sample with snippets so we can further help?

[github-actions]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.