Vscode Language Server is preloading wrong provider version - intellisense then not working

[phx-tim-butters]

Extension Version

v2.29.4

VS Code Version

Version: 1.87.0 (user setup)
Commit: 019f4d1419fbc8219a181fab7892ebccf7ee29a2
Date: 2024-02-27T23:41:44.469Z
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.22621

Operating System

Edition Windows 11 Enterprise Version 22H2 Installed on ‎09/‎05/‎2023 OS build 22621.3155 Experience Windows Feature Experience Pack 1000.22684.1000.0

Terraform Version

Terraform v1.7.4 on linux_amd64

Steps to Reproduce

1. Specify alz provider and version

terraform {
required_providers {
alz = {
source = "azure/alz"
version = "0.8.0"
}
}

2. Use input variable only present in v.0.8.0 of the provider

provider "alz" {

lib_urls = [
"${path.root}/lib",
"github.com/MyOrg/MyRepo//some/dir?ref=v1.1.0&depth=1",
]
}

3. Observe vscode intellisense stating Unexpected Attribute

Expected Behavior

I expect vscode intellisense by means of the language server to correctly validate the input variable lib_urls

Actual Behavior

vscode intellisense stating Unexpected Attribute via the Terraform language Server

Terraform Configuration

terraform {
  required_providers {
    alz = {
      source  = "azure/alz"
      version = "0.8.0"
    }
  }

provider "alz" {

  lib_urls = [
    "${path.root}/lib"
  ]
}

Project Structure

No response

Gist

No response

Anything Else?

Output for Hashicopr Terraform in vscode shows preloaded schema;

2024/02/29 12:20:07 module_ops.go:368: preloaded schema for registry.terraform.io/azure/alz 0.6.3 in 491.58µs

Workarounds

No response

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

[dbanck]

Hi @phx-tim-butters, thanks for the port.

At the time of the last language server release two weeks ago, 0.6.3 was the latest provider version available. The next language server release will bundle the updated schema and fix the problem. Sorry for the inconvenience.

In the meantime, when you run terraform init, we'll use the matching provider schema from disk.

[phx-tim-butters]

Hi @phx-tim-butters, thanks for the port.

At the time of the last language server release two weeks ago, 0.6.3 was the latest provider version available. The next language server release will bundle the updated schema and fix the problem. Sorry for the inconvenience.

In the meantime, when you run terraform init, we'll use the matching provider schema from disk.

Hi there, Thanks for your reply.

That expands my understanding of why the Language Server uses certain version. Is there no way of forcing it to utilise the latest version of a provider at all?

[dbanck]

We bundle the latest version of all official and partner providers at build time to provide a good out-of-the-box experience. We use these schemas as a fallback, if we can't get a better matching version for your constraint.

When you run terraform init, Terraform will install your specific provider version on disk and the language server will pick that schema instead.
If you're curious, you can also find it in the log:

jobs.go:321: JOBS: Dispatching next job "6" (scheduler prio: -1, job prio: 0, isDirOpen: false): "OpTypeObtainSchema" for {"file:///Users/dbanck/tmp/issue1701"}
provider_schema.go:109: PSS: adding local schema (/Users/dbanck/tmp/issue1701, registry.terraform.io/azure/alz): 0xc00012fa88
jobs.go:461: JOBS: Finishing job "6": "OpTypeObtainSchema" for {"file:///Users/dbanck/tmp/issue1701"} (err = %!s(<nil>), deferredJobs: [])

[phx-tim-butters]

We bundle the latest version of all official and partner providers at build time to provide a good out-of-the-box experience. We use these schemas as a fallback, if we can't get a better matching version for your constraint.

When you run terraform init, Terraform will install your specific provider version on disk and the language server will pick that schema instead. If you're curious, you can also find it in the log:

jobs.go:321: JOBS: Dispatching next job "6" (scheduler prio: -1, job prio: 0, isDirOpen: false): "OpTypeObtainSchema" for {"file:///Users/dbanck/tmp/issue1701"}
provider_schema.go:109: PSS: adding local schema (/Users/dbanck/tmp/issue1701, registry.terraform.io/azure/alz): 0xc00012fa88
jobs.go:461: JOBS: Finishing job "6": "OpTypeObtainSchema" for {"file:///Users/dbanck/tmp/issue1701"} (err = %!s(<nil>), deferredJobs: [])

Ahh - so, I'm doing a Terraform Init with the specific 0.8.0 version in the requried_provider section, but my Language Server is still referencing 0.6.3.

I assumed this would be the case, and would expect a Terraform Init to fix it, but it's not.

[dbanck]

Exactly! That is how it should to work (and does for me).

Without init

After init

Can you close and reopen VS Code and then share the full log output with me?

[phx-tim-butters]

I've linked both an image and output from HashiCorp Terraform.

I performed a further Terraform Init, and still the issue continued.

Output.txt

[dbanck]

Oh, I think I know what's happening here. From the log output, it looks like you're hitting hashicorp/terraform-ls#1540

Here is what happens:

1. The language server has parsed the configuration and is reading the required providers
2. It loads the appropriate bundled schema (0.6.3)
3. It runs all kinds of jobs that depend on a schema, such as validation
4. It loads the installed schema from disk (0.8.1), which is slower than 2.
5. It doesn't re-run the validation from 3. with the newer schema

If you change the file, like inserting a space, the validation error should go away, because the language server is now using the newer schema for everything.

[phx-tim-butters]

Super star - thank you! That's working. Leave the issue open and link it to the bug? or close it?

[dbanck]

Glad we figured this out! I know modifying the file isn't a good workaround, but since it only happens once right after startup, I hope it's not too bad.

I'll add this to the bug report and see if we can prioritize it in the future. I'll close it for now, but let me know if you run into any other problems.

[dbanck]

@phx-tim-butters FYI, we just released a new version 2.29.5. This updates the schema to the latest version and should fix the validation error without having to run terraform init. The update should appear automatically in VS Code.

[phx-tim-butters]

Oh my word, that's so much better.

It's working now - Many thanks.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.