vscode-terraform: "Unexpected attribute" false alarms

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.

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

AWS EKS module also.

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.

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

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

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…