Error logging lacks information about faulty resource

[pielgrzym]

Confirmation

• This is a bug with an existing resource and is not a feature request or enhancement. Feature requests should be submitted with Cloudflare Support or your account team.
• I have searched the issue tracker and my issue isn't already found.
• I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

registry.terraform.io/cloudflare/cloudflare v3.25.0

Affected resource(s)

Any cloudflare resource.

Terraform configuration files

-

Link to debug output

Panic output

No response

Expected output

[Provider: mycloudflare_account_7 Module mymagicmodule.cloudflare_record.xyz]: Error: Authenticatin error(10000)

Actual output

Error: Authentication error (10000)

or if you search TF_LOG=TRACE you will find just a response with 403 without any link to which account/domain/resource it was related to.

Steps to reproduce

1. Some of us manage several cloudflare accounts
2. At times we need to remove a record manually from terraform state (client's domain expired and was removed from CF account automatically - you need to remove the resource from state manually. This is en arror prone process - from time to time you might leave a leftover resource pointing to non-existent CF resource.
3. When you run terraform you will get authentication error.
4. When you try to debug this error you won't have any meaningfull information indicating there is leftover resource even when using trace log.

Is it possible for the error message to include the resource which triggered the authentication error? This spares literally hours of debugging.

Additional factoids

No response

References

No response

[github-actions]

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 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.

[github-actions]

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.

This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

[jacobbednarz]

the debug (and trace) logs include this in the HTTP interactions. you search for the erroring response and the request is before it.

the terraform output also shows you the resource it is targeting in the output, here mymagicmodule.cloudflare_record.xyz.

[pielgrzym]

Hi,

Thanks for quick response. The request/response pairs are interleaved by other requests and it's laborous to uncover this info from trace, especially since many api calls do not include verbose information (for example they use ID instead of domain which adds another layer for searching the culprit). When the error occurs all I get is the unauthenticated error and not resource at all, here is example, censored output:

Terraform planned the following actions, but then encountered a problem:

  # cloudflare_zone.my_zone will be updated in-place
  ~ resource "cloudflare_zone" "my_zone" {
      - account_id          = "someid" -> null
        id                  = "someid"
        # (9 unchanged attributes hidden)
    }

  # cloudflare_zone.other_zone will be updated in-place
  ~ resource "cloudflare_zone" "other_zone" {
      - account_id          = "someid" -> null
        id                  = "someid"
        # (9 unchanged attributes hidden)
    }

Plan: 0 to add, 2 to change, 0 to destroy.

Changes to Outputs:
  - s1_ip    = [] -> null
  - s2_ip    = [] -> null
  - some_other_var    = [
      - [],
    ] -> null
  - and_var = [] -> null
╷
│ Error: Authentication error (10000)
│
│
╵

[jacobbednarz]

the output you've shown here looks to be from a terraform plan and will be lacking context as terraform attempts to refresh the resource. there isn't anything further we can do here as we're already returning a diagnostic which terraform returns to the end user. that's something you'll want to chat to the terraform core folks about if it currently missing (although i find it odd that it would). apply operations definitely have the resource associated with the diagnostic.

the request and response come one after another (much like any other HTTP client) and are sent to the logger in that order. what you're describing is a symptom of looking at all log drains instead of only the provider log drain which will include internal grpc calls and state management logging. you can view how to manage this via https://developer.hashicorp.com/terraform/plugin/log/managing

[pielgrzym]

Got it, thanks for clarification!