Skip to content
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

[Bug]: aws_amplify_app.custom_header always reports changes #34318

Open
KholdStare opened this issue Nov 8, 2023 · 8 comments
Open

[Bug]: aws_amplify_app.custom_header always reports changes #34318

KholdStare opened this issue Nov 8, 2023 · 8 comments
Labels
bug Addresses a defect in current functionality. service/amplify Issues and PRs that pertain to the amplify service.

Comments

@KholdStare
Copy link

Terraform Core Version

1.5.5

AWS Provider Version

5.24.0

Affected Resource(s)

aws_amplify_app

Expected Behavior

When using custom_headers in aws_amplify_app, running terraform plan when nothing has changed should not result in any actions.

e.g.

resource "aws_amplify_app" "amplify" {
  # ...
  custom_headers = <<EOT
customHeaders:
  - pattern: '**/*.jpg'
    headers:
      - key: Cache-Control
        value: 'public, max-age=605800, s-maxage=3600'
  EOT
}

running terraform apply followed by terraform 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 will perform the following actions:

  # module.frontend.aws_amplify_app.amplify will be updated in-place
  ~ resource "aws_amplify_app" "amplify" {
      ~ custom_headers                = jsonencode(
            [
              - {
                  - headers = [
                      - {
                          - key   = "Cache-Control"
                          - value = "public, max-age=605800, s-maxage=3600"
                        },
                    ]
                  - pattern = "**/*.jpg"
                },
              - {
                  - headers = [
                      - {
                          - key   = "Cache-Control"
                          - value = "public, max-age=605800, s-maxage=3600"
                        },
                    ]
                  - pattern = "**/*.svg"
                },
              - {
                  - headers = [
                      - {
                          - key   = "Cache-Control"
                          - value = "public, max-age=605800, s-maxage=3600"
                        },
                    ]
                  - pattern = "**/*.js"
                },
              - {
                  - headers = [
                      - {
                          - key   = "Cache-Control"
                          - value = "public, max-age=605800, s-maxage=3600"
                        },
                    ]
                  - pattern = "**/*.css"
                },
              - {
                  - headers = [
                      - {
                          - key   = "Cache-Control"
                          - value = "public, max-age=600, s-maxage=600"
                        },
                    ]
                  - pattern = "**/*.html"
                },
            ]
        ) -> <<-EOT
            # https://docs.aws.amazon.com/amplify/latest/userguide/custom-headers.html
            # https://docs.aws.amazon.com/amplify/latest/userguide/ttl.html
            # max-age controls caching on user browser's side
            # s-maxage controls cloudfront caching (how often the CDN can be refreshed)
            customHeaders:
              # Setting image, js, css caching to 7 days, because we hash the names of images
              - pattern: '**/*.jpg'
                headers:
                  - key: Cache-Control
                    value: 'public, max-age=605800, s-maxage=3600'
              - pattern: '**/*.svg'
                headers:
                  - key: Cache-Control
                    value: 'public, max-age=605800, s-maxage=3600'
              - pattern: '**/*.js'
                headers:
                  - key: Cache-Control
                    value: 'public, max-age=605800, s-maxage=3600'
              - pattern: '**/*.css'
                headers:
                  - key: Cache-Control
                    value: 'public, max-age=605800, s-maxage=3600'
              # html pages should be cached less, since their names are not hashed
              - pattern: '**/*.html'
                headers:
                  - key: Cache-Control
                    value: 'public, max-age=600, s-maxage=600'
        EOT
        id                            = "REDACTED"
        name                          = "REDACTED"
        tags                          = {}
        # (14 unchanged attributes hidden)

        # (3 unchanged blocks hidden)
    }

Terraform Configuration Files

N/A

Steps to Reproduce

  1. Create an aws_amplify_app resource with custom_headers
  2. run `terraform apply``
  3. run terraform plan

Debug Output

No response

Panic Output

No response

Important Factoids

The custom_header capability was introduced in this PR: #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 root customHeaders 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 root customHeaders 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

@KholdStare KholdStare added the bug Addresses a defect in current functionality. label Nov 8, 2023
@github-actions github-actions bot added the service/amplify Issues and PRs that pertain to the amplify service. label Nov 8, 2023
Copy link

github-actions bot commented Nov 8, 2023

Community Note

Voting for Prioritization

  • Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
  • Please see our prioritization guide for information on how we prioritize.
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

  • If you are interested in working on this issue, please leave a comment.
  • If this would be your first contribution, please review the contribution guide.

@terraform-aws-provider terraform-aws-provider bot added the needs-triage Waiting for first response or review from a maintainer. label Nov 8, 2023
@justinretzolk justinretzolk removed the needs-triage Waiting for first response or review from a maintainer. label Nov 9, 2023
@KholdStare
Copy link
Author

Hi @ewbankkit @Maddog2050! Just pinging if you saw this. The changes merged recently here #31560 have a bug.

@KholdStare
Copy link
Author

@justinretzolk @ewbankkit @Maddog2050 Pinging again, since this prevents us from using the custom_header functionality through terraform.

@KholdStare
Copy link
Author

@justinretzolk @ewbankkit @Maddog2050 Pinging again - It has been several months.

@brettboylen
Copy link

This would be great if this could be fixed.

@gsi-eric
Copy link

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.

@KholdStare
Copy link
Author

@justinretzolk @ewbankkit @Maddog2050 Pinging again :) It has been 9 months of this issue.

@ebottani-verity
Copy link

Hey amazing folks, I'm supporting @KholdStare on this request. Any idea when this could be fixed? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Addresses a defect in current functionality. service/amplify Issues and PRs that pertain to the amplify service.
Projects
None yet
Development

No branches or pull requests

5 participants