Vscode Language Server is preloading wrong provider version - intellisense then not working about vscode-terraform HOT 12 CLOSED

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.

from vscode-terraform.

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?

from vscode-terraform.

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

from vscode-terraform.

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.

from vscode-terraform.

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?

from vscode-terraform.

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

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

Output.txt

from vscode-terraform.

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.

from vscode-terraform.

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

from vscode-terraform.

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.

from vscode-terraform.

@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.

from vscode-terraform.

Oh my word, that's so much better.

It's working now - Many thanks.

from vscode-terraform.

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.

from vscode-terraform.