Open KholdStare opened 1 year ago
Voting for Prioritization
Volunteering to Work on This Issue
Hi @ewbankkit @Maddog2050! Just pinging if you saw this. The changes merged recently here https://github.com/hashicorp/terraform-provider-aws/issues/31560 have a bug.
@justinretzolk @ewbankkit @Maddog2050 Pinging again, since this prevents us from using the custom_header functionality through terraform.
@justinretzolk @ewbankkit @Maddog2050 Pinging again - It has been several months.
This would be great if this could be fixed.
This would be great if this could be fixed. This issue makes it difficult to read the Terraform plan by adding the message each time. This error does not allow us to determine if there are changes to custom headers or not.
@justinretzolk @ewbankkit @Maddog2050 Pinging again :) It has been 9 months of this issue.
Hey amazing folks, I'm supporting @KholdStare on this request. Any idea when this could be fixed? :)
Terraform Core Version
1.5.5
AWS Provider Version
5.24.0
Affected Resource(s)
aws_amplify_app
Expected Behavior
When using
custom_headers
inaws_amplify_app
, runningterraform plan
when nothing has changed should not result in any actions.e.g.
running
terraform apply
followed byterraform plan
should not result in any changes reported.Actual Behavior
In actuality no matter what content is stored in
custom_headers
, it is always deemed changed.Relevant Error/Panic Output Snippet
Terraform Configuration Files
N/A
Steps to Reproduce
aws_amplify_app
resource withcustom_headers
terraform plan
Debug Output
No response
Panic Output
No response
Important Factoids
The custom_header capability was introduced in this PR: https://github.com/hashicorp/terraform-provider-aws/pull/31561 . I suspect that the AWS API does not return exactly what was originally set on the
custom_headers
. Specifically you will notice below that the reported current value by AWS is missing the rootcustomHeaders
key. It looks like AWS normalizes the string that is sent through the custom header api.Perhaps the solution is to normalize the user-provided string on the provider side (e.g. through
jsonencode(yamldecode(...))
), but also taking care of the fact that AWS reports the value without the rootcustomHeaders
key. Attempting to set a value without that root key results in an error from the AWS PI.References
No response
Would you like to implement a fix?
None