Api Gateway Deployment not updated when AutoPublishAlias is changed

[zroger]

Description:

When changing the value of AutoPublishAlias on a function resource, the new alias was created, the old alias deleted, and the associated API Gateway resources were updated. However, a new deployment was not created, leaving the API Gateway stage pointed at the previous function alias.

This seems to be only a problem when using inline swagger.

Steps to reproduce the issue:

1. Starting from the inline_swagger example, add an AutoPublishAlias with the value v1 to the function resource, and change the reference in the swagger to ${MyLambdaFunction.Alias}.
2. Deploy this template to a new stack.
3. Update the value of the AutoPublishAlias property to v2.
4. Create a new changeset.

Observed result:
The created changeset contains the following:

• Modify the MyApi AWS::ApiGateway::RestApi resource
• Modify the MyLambdaFunctionGetApiPermissionprod AWS::Lambda::Permission resource
• Add the MyLambdaFunctionAliasv2 AWS::Lambda::Alias resource
• Remove the MyLambdaFunctionAliasv1 AWS::Lambda::Alias resource.

Expected result:
A changeset that also creates a new deployment resource and updates the stage.

[jfuss]

The cause of this is in how SAM generates the logical id for the API Gateway Deployment resource. This is done by hashing the inline swagger that is generated or provided which does not resolve all the intrinsics, since SAM relies on CloudFormation to do that after SAM is done.

Doing this now automatically is problematic as it will create redeployment for customers. Maybe that is the right thing here but we need to make sure we don't cause issues for customers when this happens. In the past (for similar things like Layers), we have caused stacks to get into un-deployable state due to throttling caused by to many updates at once. So we would need to be cautious here. Maybe we need to create a new property to make it opt in, but to solve this we either need to find a way to generate new logical ids for cases like this or resolve intrinsics. Generally/historically, we have shy'ed away from resolving intrinsics as this causes us to re-implement CloudFormation and would need to keep up to date with new ones.

[hoffa]

You might be able to get this to work by adding AWS::LanguageExtensions to Transform as such:

Transform:
  - AWS::LanguageExtensions
  - AWS::Serverless-2016-10-31

AWS::LanguageExtensions resolves intrinsic functions if the value is known when Transforms are run.

See #2533 for more information.

[hoffa]

Closing in favor of #2533.