"Unexpected attribute" false alarms

[jmcmillan1873]

Extension Version

v2.29.3

VS Code Version

Version: 1.85.2 (user setup)
Commit: 8b3775030ed1a69b13e4f4c628c612102e30a681
Date: 2024-01-18T06:40:10.514Z
Electron: 25.9.7
ElectronBuildId: 26354273
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Windows_NT x64 10.0.22621

Operating System

Edition Windows 11 Enterprise Version 22H2 Installed on ‎13/‎12/‎2023 OS build 22621.3007 Experience Windows Feature Experience Pack 1000.22681.1000.0

Terraform Version

Terraform v1.7.1 on windows_amd64 + provider registry.terraform.io/hashicorp/aws v5.32.1

Steps to Reproduce

1. Open vscode
2. Create a file named vpc.tf
3. Configure as follows:

module "vpc" {
  source               = "terraform-aws-modules/vpc/aws"
  version              = "5.5.1"
  
  name                 = var.vpc_name
  cidr                 = var.vpc_cidr
  azs                  = local.azs
  intra_subnets        = local.intra_subnets
  private_subnets      = local.private_subnets
  create_igw           = false
  enable_nat_gateway   = false
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = merge(
    var.default_tags
  )

}

5. Install and enable the official Hashicorp terraform for visual studio code.

Expected Behavior

I don't expect the Hashicorp terraform extension to highlight the above code as having any 'problems'.

Actual Behavior

1. The Hashicorp Terraform extension incorrectly identifies many of the parameters supplied to the VPC module configuration as being unexpected e.g.

Unexpected attribute: An attribute named "name" is not expected here Terraform

2. The parameters that are highlighted as problems are all valid according to the Inputs section of the VPC module documentation. Also performing terraform validate on the command line confirms that the code is fine.

3. Finally - and this is difficult to reproduce as it's not consistent - hovering over the highlighted problems in the code mostly shows the error:
   Unexpected attribute: An attribute named "name" is not expected here Terraform.

However, occasionally it simultaneously display the 'unexpected' error as well as 'usage' message for the parameter it says should be there. See the attached image.

Terraform Configuration

No response

Project Structure

No response

Gist

No response

Anything Else?

The AWS toolkit extension was enable when I first encountered this issue.
I disabled the AWS extension and reloaded - so no other extensions were enabled during my steps to reproduce for this report.

Workarounds

None.

References

No response

Help Wanted

• I'm interested in contributing a fix myself

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue 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
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[stefan-matic]

Seeing these as well recently. I've been using the exact same AWS VPC setup as always.

[asychev]

+1, very annoying issue

[TarekAS]

Weird that it's happening only on the aws vpc module, any idea why?

[alxdrl]

It does also happen with the google vpc module

(this is with v2.29.4)

[snowzach]

AWS EKS module also.

[dbanck]

Thanks for all the reports! Unfortunately, I haven't been able to reproduce the problem yet :/

@TarekAS @aderuelle @snowzach Are you all running Windows? Can you share more info about your environment? Like OS, Terraform version, did you run terraform init? Maybe we can find a common denominator.

[snowzach]

Running VS Code on PopOS 22 and then Remote-SSH Plugin to Ubuntu 22.04.03 machine. Terraform v1.7.3 installed on that machine if it matters. Did try terraform init -upgrade with no help. Feel free to let me know anything else I can do to get you more debug info..

[TarekAS]

Thanks for all the reports! Unfortunately, I haven't been able to reproduce the problem yet :/

@TarekAS @aderuelle @snowzach Are you all running Windows? Can you share more info about your environment? Like OS, Terraform version, did you run terraform init? Maybe we can find a common denominator.

macOS for me (M1 chip), Terraform v1.7.3

[jmcmillan1873]

So I've just opened that repo up for the first time in a week and now the error has gone.
I've had an update to VS Code in that time.

The Hashicorp tf extension is the same version, i.e.
v2.29.3

But the VS Code Version is now
Version: 1.86.0 (user setup)
Commit: 05047486b6df5eb8d44b2ecd70ea3bdf775fd937
Date: 2024-01-31T10:28:19.990Z
Electron: 27.2.3
ElectronBuildId: 26495564
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Windows_NT x64 10.0.22621

[stefan-matic]

Experiencing the same as @jmcmillan1873 now, seems to have gone away after VS Code update.

[henworth]

I'm still experiencing this and both the extension and VS Code are fully to up date. It will go away if I reload the window but will inevitably return, seemingly once it has finished walking all the files in the workspace.

Edit: Removing the .terraform directory are re-initializing seems to have resolved for the time being.
Edit pt2: That didn't last long. It has returned.

Extension: v2.29.4

VS Code:
Version: 1.86.2
Commit: 903b1e9d8990623e3d7da1df3d33db3e42d80eda
Date: 2024-02-13T19:42:12.210Z
Electron: 27.2.3
ElectronBuildId: 26908389
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Darwin arm64 23.2.0

Terraform: v1.7.3 (this doesn't seem to make a difference, also happened on 1.6.2)

I captured this from the output when I hovered over a line:

2024/02/22 09:08:42 rpc_logger.go:32: Incoming request for "textDocument/hover" (ID 51): {"textDocument":{"uri":"file:///Users/henworth/code/terraform/aws/us-east-1/vpc/main.tf"},"position":{"line":98,"character":22}}
2024/02/22 09:08:42 provider_schema.go:306: PSS: getting provider schema (/Users/henworth/code/terraform/aws/us-east-1/vpc, registry.terraform.io/hashicorp/aws, ~> 5.0)
2024/02/22 09:08:42 hover.go:35: Looking for hover data at "main.tf" -> hcl.Pos{Line:99, Column:23, Byte:2167}
2024/02/22 09:08:42 hover.go:37: received hover data: (*lang.HoverData)(nil)
2024/02/22 09:08:42 rpc_logger.go:48: Error for "textDocument/hover" (ID 51): [-32098] main.tf (99,23): unknown attribute "default_security_group_ingress"
2024/02/22 09:08:42 opts.go:215: Completed 1 requests [10.762625ms elapsed]
[Error - 9:08:42 AM] Request textDocument/hover failed.
  Message: main.tf (99,23): unknown attribute "default_security_group_ingress"
  Code: -32098 

I've also attached an attempt to capture all relevant output once startup finishes post window reload, right when it marks the file as having errored lines.
vs_code_logs.txt

[isaac-gomez-azumo]

Same issue with aws_cloudfront_distribution:

Extension: v2.29.4
VS Code:
Version: 1.85.1
Commit: 0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2
Date: 2023-12-13T09:47:11.635Z
Electron: 25.9.7
ElectronBuildId: 25551756
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Linux x64 5.15.145

Terraform: v1.7.4
on linux_amd64

[dbanck]

Note to self (or anyone else picking this up):

I was able to accidentally reproduce the problem while investigating something else. It looks like when the registry request fails with a timeout (other errors seem fine), we are making incorrect assumptions about the module schema.

2024/02/27 14:36:57 jobs.go:461: JOBS: Finishing job "11": "OpTypeGetModuleDataFromRegistry" for {"file:///Users/dbanck/tmp/modules2"} (err = 1 error occurred:
	* Get "https://registry.terraform.io/v1/modules/terraform-aws-modules/eks/aws/versions": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

, deferredJobs: [])

[remiflament]

Also happen in resource aws_kinesis_firehose_delivery_stream with the attribute custom_time_zone

resource "aws_kinesis_firehose_delivery_stream" "cdc" {
  name        = "${local.project}-${local.workspace}"
  destination = "extended_s3"

  extended_s3_configuration {
    # ...
    custom_time_zone   = "Europe/Paris"
    # ...
    }
  }
}

[DevoFalcon]

Weird that it's happening only on the aws vpc module, any idea why?

I'm seeing this with "terraform-google-modules/network/google" as well. It seems like repos with both a top-level module and submodules are where it fails.

I have a file where I use both the terraform-google-modules/network/google module and the terraform-google-modules/network/google//modules/network-peering module. Vscode is attempting to validate the first one as though it was network-peering. When I remove my instance of network-peering from the file, then validation works for the first one

[jamesdfleming]

For me, I get the errors showing up with this module source:
source = "registry.terraform.io/terraform-aws-modules/iam/aws//modules/iam-assumable-role"

But they go away if I get rid of the double forward slash:
source = "registry.terraform.io/terraform-aws-modules/iam/aws/modules/iam-assumable-role"

However the latter doesn't work in terraform. Just thought this might help with reproducing it?

[borrell]

Having the same error with an AWS resource

Logged into remote SSH host:

Version: 1.87.2 (user setup)
Commit: 863d2581ecda6849923a2118d93a088b0745d9d6
Date: 2024-03-08T15:20:17.278Z
Electron: 27.3.2
ElectronBuildId: 26836302
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Windows_NT x64 10.0.19045

Terraform 1.7.5 on Amazon Linux 2023 x86_64.

[TinaHeiligers]

I see the same issue with locals that are defined in a different .tf file

[paul-civitas]

How is the code getting what attributes are expected with each resources? Because that can vary depending on the provider versions, which are different per project.

You're going to get a lot of wrong behavior if you hardcode that for a particular provider particular attributes are expected.

[dbanck]

Having the same error with an AWS resource

Hi @borrell, this sounds like a different issue. Would you mind creating a new one with more details?

I see the same issue with locals that are defined in a different .tf file

Hi @TinaHeiligers, this sounds like a different issue. Would you mind creating a new one with more details?

How is the code getting what attributes are expected with each resources? Because that can vary depending on the provider versions, which are different per project.

Hi @paul-civitas, we bundle the latest provider schema with the language server at build time to provide a better out-of-the-box experience. If a user has Terraform installed and has run terraform init, we prefer the schema of the locally installed provider instead to ensure a better match. The schema contains all resources, datasources and their attributes.

For modules, we can get the schema from the registry, which should always ensure a matching version. Here it looks like there is an edge case when fetching module schemas on an unstable connection.

[TinaHeiligers]

Hi @TinaHeiligers, this sounds like a different issue. Would you mind creating a new one with more details?

@dbanck my issue turned out not to be a problem, my workspace was old

[paul-civitas]

we bundle the latest provider schema with the language server at build time to provide a better out-of-the-box experience

Hey @dbanck that's EXACTLY the issue. That's why I think this is coming up.

If a user has Terraform installed and has run terraform init, we prefer the schema of the locally installed provider instead to ensure a better match

It seems the schema of the locally installed provider doesn't get picked up sometimes, which leads to the issue I'm experiencing. It's not very clear in the extension when it's using a baked in schema and when it's using one from the locally installed provider.

[isaac-gomez-azumo]

After this information I found the autodetect schema is assuming you are working in a single project. I have a folder with multiple projects and the modules folder. The extension reads the first folder with .terraform/providers/registry.terraform.io/hashicorp/aws, in my case I have providers versions 3.75.2 and 4.27.0. The extension takes 4.27.0. However the module I`m working is for a project with version 5.40.0 that is in a later folder.

If I specify the provider version in the module folder the false alarms disappear.

terraform {
  required_version = ">= 1.3"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">=5.40"
    }
  }
}

Hope this helps.

[paul-civitas]

Ahh yes this tracks with my use case. My workspace probably has 100 or so git repos in it. And some portion of them have terraform. Each one has a terraform version configured using asdf and its own settings on provider and provider versions.

I understand if the maintainers want to focus on a single terraform repo with terraform per workspace, and a single terraform version that's set globally. But unfortunately that doesn't always reflect the reality of production codebases.

[iramello]

still happening on 2.29.5 (using terraform-aws-lambda module).

[marcoceppi]

After this information I found the autodetect schema is assuming you are working in a single project. I have a folder with multiple projects and the modules folder. The extension reads the first folder with .terraform/providers/registry.terraform.io/hashicorp/aws, in my case I have providers versions 3.75.2 and 4.27.0. The extension takes 4.27.0. However the module I`m working is for a project with version 5.40.0 that is in a later folder.

This is a similar issue to me, with the terraform-aws-modules/vpc/aws module. We are in the process of refactoring terraform from a single module in the root directory to sub-dirs with their own state and lock files. If the parent directory has a .terraform folder the extension errors in the ways described here. If I delete that .terraform folder in the root of the repo it seems to find the correct .terraform dir in the module directory.

I wasn't able to reproduce this, it happened again and the only solution that seems to resolve it; even if temporarily; is to reload the window.

Are there any logs or different modes to run this which may help provide additional information / context?

[MakMao]

I have the same issue. When renaming the tfvars file, the problem disappears. When adding another value to tfvars file, the problem occurs again. Very annoying issue

EDIT: For me this error seemed to be happening when having the HashiCorp Terraform extension and the Terraform Advanced Syntax Highlighting extension enabled at the same time in vscode. So, I turned off the latter.

[cloud303-cholden]

FWIW the issue disappeared when I removed the required_version from the terraform block in my main.tf.

[claytonolley]

For me it seems to trigger when I use version constraints instead of specific versions.

source  = "foo/blah/aws"
version = "~> 4.0"

[airrloww]

had the same issue on GCP, restarted the HashiCorp Terraform extension on VS code and the error is gone.
HashiCorp Terraform v2.30.1

[omerfarukabaci]

❌ It was also happening to me while using cloudflare provider, only for cloudflare_record resource:

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

Terraform Version: 1.7.4
Cloudflare Version: 4.40.0

---

✅ Updated to TF version 1.9.5, restarted HashiCorp Terraform extension and it is fixed! 🚀

[giorgioGTelian]

i want to add a comment for the people that cannot apply @isaac-gomez-azumo solution.
for now i dit not find one plan and apply work perfectly.
i also have to use an older version 1.5.6, anybody can help me?