-
Notifications
You must be signed in to change notification settings - Fork 9.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aws_cloudfront_distribution diffs didn't match during apply #8271
Comments
I believe it may be a duplicate of: #6527. The symptom is similar, and I can also fix it by hardcoding the |
This still an issue on 0.7.8, is there any workaround for it? |
Seems to still be b0rked in 0.7.10. Worked around it by manuall configuring CloudFront for now. |
Still failing in 0.7.11. |
This fixes some edge-ish cases where a set in a config has a set or list in it that contains computed values, but non-set or list values in the parent do not. This can cause "diffs didn't match during apply" errors in a scenario such as when a set's hash is calculated off of child items (including any sub-lists or sets, as it should be), and the hash changes between the plan and apply diffs due to the computed values present in the sub-list or set items. These will be marked as computed, but due to the fact that the function was not iterating over the list or set items properly (ie: not adding the item number to the address, so set.0.set.foo was being yielded instead of set.0.set.0.foo), these computed values were not being properly propagated to the parent set to be marked as computed. Fixes hashicorp#6527. Fixes hashicorp#8271. This possibly fixes other non-CloudFront related issues too.
This fixes some edge-ish cases where a set in a config has a set or list in it that contains computed values, but non-set or list values in the parent do not. This can cause "diffs didn't match during apply" errors in a scenario such as when a set's hash is calculated off of child items (including any sub-lists or sets, as it should be), and the hash changes between the plan and apply diffs due to the computed values present in the sub-list or set items. These will be marked as computed, but due to the fact that the function was not iterating over the list or set items properly (ie: not adding the item number to the address, so set.0.set.foo was being yielded instead of set.0.set.0.foo), these computed values were not being properly propagated to the parent set to be marked as computed. Fixes hashicorp#6527. Fixes hashicorp#8271. This possibly fixes other non-CloudFront related issues too.
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. |
Hi,
I've got an issue creating an S3 bucket, with an associated CloudFront distribution and Origin Access Identity:
aws_cloudfront_distribution.super-magic-bucket-for-terraform-bug-report: diffs didn't match during apply.
When I create these components independently I don't experience the issue.
Also, if I remove
origin_access_identity
froms3_origin_config
in the CloudFront distribution it works fine.Terraform Version
0.7.0
Affected Resource(s)
Terraform Configuration Files
Debug Output
https://gist.github.com/lussier/1474a898edff60159cc49f490120b82a
Panic Output
None
Expected Behavior
It should have:
Steps to Reproduce
terraform apply
on the provided configurationImportant Factoids
No, nothing special
The text was updated successfully, but these errors were encountered: