Unexpected attribute: An attribute named "content" is not expected here

[liamdawson]

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

Terraform v1.9.4
on darwin_arm64
+ provider registry.terraform.io/cloudflare/cloudflare v4.39.0

Affected resource(s)

cloudflare_record

Terraform configuration files

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "4.39.0"
    }
  }
}

provider "cloudflare" { }

resource "cloudflare_record" "record" {
  zone_id = "my-zone-id"
  name    = "my-record"

  type    = "A"
  content = "127.0.0.1"
  proxied = false
}

Link to debug output

https://gist.github.com/liamdawson/15b2dc72cdc9e2a3447a7fda541c79b4

Panic output

No response

Expected output

The resource would validate correctly in the Visual Studio Code Terraform extension (which uses the Terraform LSP).

Actual output

The line with content is marked with an error:

Unexpected attribute: An attribute named "content" is not expected here    Terraform  [Ln 6, Col 3]

Steps to reproduce

1. Open a folder in Visual Studio Code
2. Enable the hashicorp.terraform extension
3. Create a main.tf with the resource above
4. terraform init
5. Close and re-open main.tf

Additional factoids

Interesting snippet in the verbose terraform plan output:

2024-08-17T13:17:54.982+1000 [WARN]  Provider "registry.terraform.io/cloudflare/cloudflare" produced an invalid plan for cloudflare_record.record, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .allow_overwrite: planned value cty.False for a non-computed attribute

References

• Confusing error message pertaining to deprecation of "value" attribute of cloudflare_record #3590 may be related?

[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]

Terraform debug log detected ✅

[liamdawson]

Added log file: https://gist.github.com/liamdawson/15b2dc72cdc9e2a3447a7fda541c79b4

I've also reproduced the same issue in the zed editor.

[BenJackGill]

Can confirm I am also seeing this error with 4.39.0

[jacobbednarz]

this isn't a provider (or version) specific issue but instead, how the LSP determines what version of the provider to use in order to validate the configuration. for this to work properly, you'll need to:

• update the version in your configuration (4.38.0 => 4.39.0)
• terraform init -upgrade
• open your editor

from there, you'll get the correct LSP feedback.

[billinghamj]

@jacobbednarz I don't think that's right. Even on the latest version, even having explicitly updated the provider version constraint from "~> 4.2" to "~> 4.39", and restarting the language server, the issue remains

[angelcabrera-nr]

The bug is still present in version 4.40

provider "registry.terraform.io/cloudflare/cloudflare" {
version = "4.40.0"
...

"Unexpected attribute: An attribute named "content" is not expected here"

[jacobbednarz]

providers don't do anything specifically for the LSP to work other than define the schema (which here, is identical to value). it relies on the output from terraform providers schema -json output which is why you see errors between versions if you don't upgrade/select the correct version. very common issue with version managers (asdf, tf env, etc).

[BenJackGill]

Did you run terraform init -upgrade? Mine seems to be fixed now, using 4.39.0

EDIT: I spoke too soon. I am also still seeing this error even after running terraform init -upgrade. Not sure why it temporarily disappeared.

[BenJackGill]

I have no idea why this error keeps popping up. After upgrading to 4.39.0 and running terraform init -upgrade sometimes the error shows, and sometimes it disappears.

I've had to downgrade to 4.38.0 and use value instead until this is resolved. But also the issue is now closed so I'm not holding my breath.

If someone can shed more light onto whats happening please let me know!

[jacobbednarz]

there is no further answers from me. it comes down to how it is being picked locally.

[hfsaito]

Isn't this a breaking change added in v4.39.0? Looks like it should have been applied in v5.0.0
Everyone using ~> 4.0 now have to change the required version to ~> 4.39
(including the example shown in provider page https://registry.terraform.io/providers/cloudflare/cloudflare/4.39.0/docs)

I manage to fix my case

1. I ran terraform init -upgrade and cli commands started work like terraform validate and terraform plan
   But the lsp is not picking the correct schema, which is really annoying
   I installed it through vscode extension and left with default settings
   I ran terraform providers schema -json, looks correct, I could find the attribute in json structure
2. I have 3 different environments which share modules and the error message was showing in one of the modules

   root folder
   |-- dev
   |-- staging
   |-- prod
   |-- modules
   

3. I changed provider version to ~> 4.39 in dev and modules folders, didn't work
4. I ran terraform init -upgrade in all environments, didn't work
5. I changed provider version to ~> 4.39 in all folders it worked!

[jacobbednarz]

Isn't this a breaking change added in v4.39.0? Looks like it should have been applied in v5.0.0

no it is not a breaking change. value is still usable and will be until 5.x. content is introduced now to make the transition possible before 5.x is out.

[SeanKilleen]

I also hit this behavior and found it confusing.

• Run terraform init -upgrade with latest version of provider (4.40.0)
• Run tf plan
• See message: value is deprecated in favour of content and will be removed in the next major release.
• Change value field to content

Expected behavior: TF file appears valid with no issues
Actual behavior: see issue surfaced by LSP that content is not an expected field (even after reopening file or VSCode)

Personal workaround: Explicitly run terraform validate after changing the field. I couldn't get the LSP to pick up on the new schema on its own but running the validate command seemed to resolve things.

YMMV. Hope it helps someone out.

[hfsaito]

Isn't this a breaking change added in v4.39.0? Looks like it should have been applied in v5.0.0

no it is not a breaking change. value is still usable and will be until 5.x. content is introduced now to make the transition possible before 5.x is out.

Makes sense
There could be a warning message in the documentation below this new attribute
To tell us to change the required version to 4.39

[jacobbednarz]

the change is documented in the changelog (https://github.com/cloudflare/terraform-provider-cloudflare/blob/master/CHANGELOG.md#4390-august-7th-2024) and in the terraform output itself when using the deprecated value.

[domenikk]

I ran into the same issue with latest version (4.40). The only thing that worked for me was switching to pre-release version of HashiCorp Terraform extension in VSCode: v2.33.2024082314