Terraform: Nothing to update in cloudformation should not result in errors

Created on 16 Mar 2016  ยท  8Comments  ยท  Source: hashicorp/terraform

When a cloudformation template is updated, but the update does not result in any resource changes cloudformation responds with HTTP 400 ValidationError: No updates are to be performed.

Here is an example gist showing the problem.

Would it be possible to not propagate this specific error from the AWS API or avoid updating the stack when there are no resource changes?

bug provideaws

Most helpful comment

Still happening today. Any way of getting around this for the moment?

All 8 comments

I am hitting the same issue.

I also noticed the same behavior when using the aws-cli indicating that this is the SDK's default behavior, which seems wrong imo. So it seems that terraform should catch this specific exception and keep going.

This is still an issue almost a year later. I assume terraform just sees the 400 that AWS returns in the status code and counts it as an error. Is it very hard to be able to go deeper on cloudformation api calls to check the error string?

I think this is something that AWS should really fix as I dont think having no updates is really a client error at all or an error in any form - but in the mean time it would be great for terraform have an exception for that particular error string...

Still happening today. Any way of getting around this for the moment?

I have spoken with the AWS Cloudformation team and they have said that they will not be changing the response from the API, so in order for this to be fixed Terraform will need to inspect the error message. As per AWS Cloudformation's comments:

I would recommend the client not look at the HTTP code and instead look at the AmazonServiceException's error code which will have a string name which is 'ValidationError' and if they need to separate this from something like a bad parameter specification, the message of "No updates are to be performed" should be matched.

Would be nice for this commitment of aws cloudformation team to be documented in the API (javadoc on method for instance). That would mean I don't have to google for issues like this.

It's been fixed now but I don't think Hashicorp should be the ones documenting it. This is AWS's call and they can change to abide by standard HTTP error codes anytime.

thanks, my mistake I thought I was commenting on the aws-sdk site. I might go mention it there because I'm relying on the commitment given to you also.

I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

Was this page helpful?
0 / 5 - 0 ratings