Many official providers have outdated schemas that are breaking changes

[danielskowronski]

Language Server Version

v0.36.5

Terraform Version

Terraform v1.12.2 on darwin_arm64

Client Version

VS Code

Terraform Configuration

resource "helm_release" "nginx_ingress" {
  name       = "nginx-ingress-controller"
  repository = "https://charts.bitnami.com/bitnami"
  chart      = "nginx-ingress-controller"

  set = [
    {
      name  = "service.type"
      value = "ClusterIP"
    }
  ]
}

Steps to Reproduce

1. Use any of freshly released official providers that are using Terraform Plugin Framework, for example helm 3.0.2
2. Adopt new required syntax

Expected Behavior

terraform-ls is either:

• rebuilt immediately every time official provider has breaking change introduced and bundled into new version of vscode-terraform
• capable of updating schemas itself, as users do not naturally expect it to be offline version of registry in one binary that is bundled with NPM package of VS Code plugin

Actual Behavior

• terraform-ls is claiming syntax is incorrect while terraform binary claims otherwise (see referenced issues)
• it identifies last version of provider it knows about and not one that is discoverable by terraform provider schema

Gist

No response

Workarounds

No response

References

Growing list of issues under https://github.com/hashicorp/vscode-terraform/issues?q=is%3Aissue%20state%3Aopen%20%22not%20expected%22 that are ignored, because problem is not with VS Code extension.

Examples:

• Syntax highlight is broken for new version of helm provider vscode-terraform#1974
• helm_release - attribute named "set" is not expected here vscode-terraform#2063
• Unexpected attribute: An attribute named "kubernetes" is not expected here vscode-terraform#2059

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

[franklouwers]

Pending an official reaction, has anyone found a workaround?

[SerhiiRohoza]

Pending an official reaction, has anyone found a workaround?

For VS Code you can temporally disable "HashiCorp Terraform" and use "OpenTofu (official)" to check and highlight syntax. It's not ideal, but could be used for a while.

[jpogran-hashi]

👋 I don't work on terraform-ls anymore, but I wanted to help explain some things.

The issue is not about terraform-ls being unable to dynamically resolve schemas, terraform-ls does dynamically resolve provider schemas at runtime for locally installed providers. The problem space is more nuanced.

This document has more detailed information https://github.com/hashicorp/terraform-ls/blob/main/docs/schema.md, I've copy/pasted some relevant sections here.

Our terraform-ls uses a three-tier approach to schema resolution:

1. Terraform built-in schema (for core constructs)
2. Bundled provider schemas (compiled at build time as fallback)
3. Locally installed providers (dynamically resolved via terraform providers schema -json)

In the documentation we describe the actual issue:

Provider schema selection is done on a best effort basis. We always try to pick the best matching version for the given provider constraints. For complex multi-root workspaces, this is difficult to get right, especially when modules don't have a direct link to a root module.

The problem occurs most often in multi-root workspace scenarios or monorepo type folders where:

• Multiple provider versions exist: Different directories have different provider versions installed (e.g., production has AWS 5.68.0, staging has AWS 5.72.1
• Ambiguous module context: Shared modules (like the example "module c") don't have a clear link to which root module's provider version they should use
• Best-effort selection fails: terraform-ls struggles to determine which provider schema version to apply, potentially falling back to bundled schemas or picking the wrong local version

The "Enhanced validation" feature compounds the experience:

We treat the internal schema as the source of truth, so whenever we detect an extraneous or missing attribute or block, we raise an error. But if our internal schema versions don't match the exact version of a provider in use, this can lead to false negatives.

It's not that terraform-ls can't resolve schemas dynamically - it can and does. The issue is that in complex workspace setups, terraform-ls can't reliably determine which of the available schema versions to use for a given file with the information it has available at that time, leading to mismatched validation between what terraform CLI uses and what the language server validates against.

This explains why you see "attribute not expected" errors even though terraform CLI works fine - terraform CLI has downloaed providers itself and has clear context about which versions to use, while terraform-ls does not have access to this information at all times.

Frequent releases of terraform-ls alleviate the issue somewhat, running terraform init helps, and opening VS Code at the source of work instead of monorepo or multi-root workspaces.

[gemyago]

@jpogran-hashi looks like it's exactly the situation I have (monorepo). Is there by any chance some way to tell terraform-ls which folder to use to look for schemas? Feels like it's just using some fallback because I don't have 2.17.0 anywhere in the repo (I have 3.0.2) and it still shows it. Some cache somewhere?

[franklouwers]

@jpogran-hashi thanks for the explanation. Most of my TF repo's look like this:

.
├── modules
│   ├── cognito
│   │   ├── _providers.tf
│   │   ├── _variables.tf
│   │   ├── client-oauth2.tf
│   │   ├── main.tf
│   │   └── users.tf
│   ├── ecr
│   │   └── main.tf
│   ├── kubernetes
│   │   ├── _versions.tf
│   │   ├── alb-ingress.tf
│   │   ├── cert-manager.tf
│   │   ├── external-dns.tf
│   │   ├── iam.tf
│   │   ├── karpenter.tf
│   │   ├── main.tf
│   │   ├── metrics.tf
│   │   ├── network.tf
│   │   ├── prometheus.tf
│   │   ├── templates
│   │   │   ├── cert-manager.yaml
│   │   │   ├── external-dns.yaml
│   │   │   ├── ingress-alb.yaml
│   │   │   ├── kube-prometheus-stack-values-full.yaml
│   │   └── variables.tf
...
└── workloads
    ├── production
    │   ├── 1p.tf
    │   ├── main.tf
    │   ├── network.tf
    │   ├── peering.tf
    │   ├── sites.tf
    │   └── variables.tf
    └── staging
        ...

I have modules (from which I never run a terraform command), and then different workloads under the workloads folders. In this case, there are modules for Kubernetes, ECR, Cognito etc, which contain platform-independent code, and both a production and staging workload, which contain references to the modules, and all env-specific parameters/vars/credentials/....

I only have a .terraform.lock.hcl and .terraform/ file/folder in each of the workloads. NOT in any of the modules folders.

The one that's bother me most, is the Helm provider. I have upgraded both workloads to the 3.x helm providers, yet the terraform-ls LSP still uses the old syntax (set {) instead of the new (set = {) one.

Could it get the syntax / module version from elsewhere?

[burner1024]

It's not that terraform-ls can't resolve schemas dynamically - it can and does.

No, it doesn't. As demonstrated here.

[mrludohenny]

I had the same problem with my Helm provider (v 3.0.0). What solved it was:

1. Update the providers schema as mentioned by @jpogran-hashi with: terraform init
2. Reload the Language Server by pressing Ctrl+Shift+P (or Cmd+Shift+P on Mac), type and select: Terraform: Reload Language Server

[ironashram]

hashicorp are really doing everything in their power to make people search for alternatives lately, well they're succeeding

[andrewbcoyle]

I had the same problem with my Helm provider (v 3.0.0). What solved it was:

1. Update the providers schema as mentioned by [@jpogran-hashi](https://github.com/jpogran-hashi) with: `terraform init`

2. Reload the Language Server by pressing `Ctrl+Shift+P` (or `Cmd+Shift+P` on Mac), type and select: `Terraform: Reload Language Server`

This worked for me as well. Nice job!