Diff of string and int results in "No changes"

[viraptor]

When running diff on a stack:

-        "Cpu": 256,
-        "Memory": 512,
+        "Cpu": "256",
+        "Memory": "512",
         "NetworkMode": "awsvpc"
       }
     },
     "Cluster": {
       "Type": "AWS::ECS::Cluster"
     }
   },
Parameters diff: No changes
The submitted information didn't contain changes. Submit different information to create a change set.

This should't be seen as a change.

[patrobinson]

CloudFormation is what reports there are "no changes". I think, under the hood, there's some type coercion going on and StackMaster is just not recognising it but I haven't looked deep into the issue.

[simpson-ross]

This is still a consistent issue, 8 years later!

-ShardCount: '1'
+ShardCount: 1

-FirehoseBufferingInterval: '120'
+FirehoseBufferingInterval: 120

It would be great to find the issue and/or a workaround here if we need one.

[orien]

I'm not clear on the specifics, are we talking about a parameter diff or a template diff?

The the diff in the tool output of the original issue description looks like a CloudFormation template. Given CloudFormation stores a copy of the template, it seems appropriate to display a diff if there are any changes between the current and the proposed templates.

[simpson-ross]

@orien sorry for not providing context 🤦

In my case, it's a parameters diff:

Parameters diff:
 ---
-FirehoseBufferingInterval: '120'
+FirehoseBufferingInterval: 120

Tracing it backwards:

• The CloudFormation template (Ruby/SF) defines this parameter as type Number, with a default value of 120
• The IntervalInSeconds parameter it's being passed to is type Integer

There is no override value passed in from a parameters file, so the default value applies. Every time an apply is run on this stack (and a number of others with similar configuration), a diff is reported like this, where the "old" value is being erroneously evaluated as a string, and generates a diff.

I didn't notice the original issue was in a template, but I think Pat's assessment is right in that there's probably some casting going on somewhere, I just haven't been able to discover where. As far as I can tell it's upstream of the diff code.

[orien]

The "The submitted information didn't contain changes. Submit different information to create a change set." message comes from CloudFormation, while there are changes to the template, the changes don't result in a change to any underlying AWS resources. Hence, its refusal to create a change set.

I believe we could "force" a change set to be created in this case to update the template in CloudFormation's stack state.

[orien]

Thanks for the context, Ross. I'll take a look. There should be a way to smooth this out in StackMaster.

In the meantime, you could try specifying the default value in the template as a string literal. This seems strange, but it matches the type in the template schema.

[orien]

I've proposed a fix for the default parameter value problem in #394.

[orien]

I've proposed an improvement to the error message displayed when CloudFormation refuses to create a change set in #398.