Changing a CustomResource resourceType or lambdaProvider requires deleting and recreating the custom resource

[ccurrie-amzn]

#943 added support for custom resource types, which is great. However, updating the custom resource type is a destructive action that requires replacement; the CDK tries to show this as a "Replace" action, but CloudFormation doesn't allow it for the same logical ID.

The workaround is to change the name of the Resource in the CDK script, but it would better if the CDK was able to detect this and change the hash of the generated Logical ID accordingly.

The same is also true for the ServiceToken key from the lambda provider. This is a more common use case where the Lambda implementation of the custom resource has changed, which redeploys the Lambda under a new ARN. The workaround here is to change the Lambda to have specify a functionName, which will prevent the ARN from changing when the Lambda changes, though moving from an unnamed to a named Lambda still requires deletion and recreation as above.

[rix0rrr]

Somewhat related to #847

[eladb]

I think tying the resource id to its type makes sense. Should be straightforward to incorporate the type into the logical ID.

It might be trickier to do that with the service token because it is resolved at deploy time. For the specific case where users pass in a lambda that uses local assets, we might be able to incorporate the asset hash into the logical ID which will achieve a similar affect I think.

[ccurrie-amzn]

The specific use case of local-asset lambdas is what broke for me, so fixing that use case would be sufficient for now.

[rix0rrr]

I'm a little confused though. I'm changing the source and redeploying all the time, feels like, and I've never run into this. Updating the source of a Lambda doesn't change its ARN.

If you change the resourceType or something immutable about the Lambda... sure, but that should be a rare occasion. Does the common case really give trouble as well?

[ccurrie-amzn]

No, source redeploys don't trigger this; I was simply saying that if the detection for ServiceToken was supported for local source lambdas only (as @eladb describe) that it would meet my needs.

In my specific case, I was refactoring my Constructs to create the lambda in a different part of the construct tree, which changed its generated name, and therefore it's ARN.

[eladb]

This is not something we are able to fix given how custom resources work.