Fn::ForEach stack updates does not trigger change

[carlnordenfelt]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about the bug

I am creating resources using Fn::ForEach. What resources to create are configured using a CommaDelimitedList Parameter. When changing the values in this list I expect resources to be created/deleted/updated but the ChangeSet does not pick up on the change:

There was an error creating this changeset
The submitted information didn't contain changes. Submit different information to create a change set. 

I can work around the problem by uploading a new, _ identical_, copy of the template. This will correctly generate a new changeset that can be deployed as expected.

Expected behavior

I should be able to change a CommaSeparatedList to change the resources generated by Fn::ForEach without having to provide the template file.

Observed behaviour

Unless the template is also updated, although identical, the changeset does not pick up on the changes.

Test cases

AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::LanguageExtensions'

Parameters:
  SgNames:
    Type: 'CommaDelimitedList'

Resources:
  Fn::ForEach::Testing:
    - 'Name'
    - !Ref 'SgNames'
    - 'Sg${Name}':
        Type: AWS::EC2::SecurityGroup
        Properties:
          GroupDescription: !Sub 'Testing ${Name}'

Additional context

I have only tested the behavior via the AWS Console.

[carlnordenfelt]

This may not be specifically related to Fn::ForEach.
I am observing the same issue when changing a condition based parameter where I also have to upload a copy of the same template for the changeset to pick up on the change.

Excerpt of this template:

AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::LanguageExtensions'

Parameters:
    NumberOfDbInstances:
    Type: 'Number'
    AllowedValues: [ '1', '2' ]

Conditions:
  EnableSecondDbInstance: !Equals [ !Ref 'NumberOfDbInstances', '2' ]

Resources:
  ...
  DbInstanceSecondary1:
    Type: AWS::RDS::DBInstance
    Condition: 'EnableSecondDbInstance'
    Properties:
      ...

Interestingly, I realized that we don't need 'AWS::LanguageExtensions' in this template and after removing that Transform it works as expected.

This can't be the expected behaviour, can it?

[krishnendubarui]

Me too..
Is there any resolution yet for this issue ?

[arthurboghossian]

This is due to the behavior of calling UpdateStack or CreateChangeSet with the UsePreviousTemplate (or --use-previous-template in the case of the AWS CLI) parameter set to true (see remark in Remarks section of doc here), where both API's use the processed template (as opposed to the unprocessed original template), and since AWS::LanguageExtensions resolves intrinsic functions, including the Fn::ForEach intrinsic function, when UpdateStack/CreateChangeSet is called on the processed template, there is no longer an intrinsic function reference to the parameter, as it was already resolved in the processed template.

i.e. if a stack is created with the following template with the parameter Param set to Value1

AWSTemplateFormatVersion: "2010-09-09"
Transform: "AWS::LanguageExtensions"
Parameters:
  Param:
    Type: String
    Default: Value1
Resources:
  WaitConditionhandle:
    Type: AWS::CloudFormation::WaitConditionHandle
Outputs:
  Output:
    Value: !Ref Param # This will be replaced with "Value1" in the processed template

the processed template would have resolved !Ref Param to Value1, where if UpdateStack or CreateChangeSet is called on this stack with UsePreviousTemplate set to true, it would fail, as no changes would be detected, since the reference to the parameter !Ref Param was replaced with Value1 in the processed template. Note: If UpdateStack or CreateChangeSet is called with UsePreviousTemplate set to false and the original template specified, if the value specified to the parameter Param is different than Value1, then the operation would succeed.

A potential resolution for this would be adding an additional parameter to the UpdateStack & CreateChangeSet API's, where if the additional parameter is specified with a specific value (Ex: true), then the original template (and not the processed template) would be used in the UpdateStack or CreateChangeSet call.

[CirrusHQ-Pipeline-User]

Is this due to be fixed? This blocks the use of the AWS::LanguageExtensions and subsequent Fn::ForEach Intrinsic Functions for advanced use cases of CloudFormation.