Autocomplete stops working from one file to another in the same module #1793
Comments
|
Hi @life5ign, Can you please check if you have the official HashiCorp Terraform extension installed? The version You can find the extension in the marketplace: https://marketplace.visualstudio.com/items?itemName=HashiCorp.terraform |
|
@dbanck sorry I accidentally copied the version from the wrong one; I do have the official extension installed, and I have version v2.30.1
|
|
Thanks for checking! Do you have multiple Terraform extensions installed? Can you share the full list of active extensions (use We have gotten similar reports in the past from people who installed some other Terraform extensions and either never installed ours ( |
|
Thanks @dbanck, I just checked and I have no other terraform extensions enabled:
|
These exact symptoms are the classic presentation of one or more extensions activating for the same language. VS Code, without prior configuration, allows any extension to provide support for any file. If two extensions advertise Terraform support, which one "wins" is entirely up to which VS Code decides to activate first, which is non-deterministic in order. This can change order every time VS Code is opened, resulting in "intermittent" behavior. In addition one extension can offer just syntax highlighting and is activated, while the other offers language server support and never is activated, resulting in the user never seeing the language server support and thinking it's broken. Differences in syntax highlighting indicate another source for the information to decide what token to highlight. We provide both TextMate based syntax highlighting as well as semantic token highlighting provided by terraform-ls. If we aren't activated, the token color you are used to seeing won't be there because terraform-ls was not started. This is the reason why we're asking about other extensions.
Unfortunately listing the names of extensions and searching for any text starting with one letter and ending with another is not going to reliably tell you if an extension is contributing features for a given language. Names of extensions are not guaranteed to have anything to do with the language they support. If you were to go this route, you would have to open each extension in the Extension Manager sidebar and examine the Features tab. Each extension has to advertise there what languages it provides features for. An easier method would be to open a Terraform file and examine the lower right hand corner. If you click on Terraform, it should look something like this: 
Another method is to examine your settings file and see if you configured VS Code to always use another extension for Terraform files: You can alternately start VS Code with an empty Profile and just the HashiCorp extension to verify that it is our extension that is not working. If that is the case, we'd love to see your User Settings and the debug log generated from a session where things are not working, and we can provide private means of submittal of this information. 
|
|
Thank you @jpogran I'm following your advice, thank you very much for your time. Does this explain how it all works fine for smaller projects though? The only thing that could be different is workspace settings I think? Regardless, here is the output from your suggested steps. Lower right terraform file format activated extensions
settingsDefaults // Configure [glob patterns](https://aka.ms/vscode-glob-patterns) of file associations to languages (for example `"*.extension": "html"`). Patterns will match on the absolute path of a file if they contain a path separator and will match on the name of the file otherwise. These have precedence over the default associations of the languages installed.
"files.associations": {},User settings "files.associations": {
"*.yml": "yaml",
"*.tf": "terraform"
},Workspace Settings
New Profile with only HC Terraform extension enabledExtensions
Depiction of issue
Debug LogI can't figure out how to generate one...all search results plus command pallete only show me stuff about the Debugger for writing code within vscode..I will happily upload it; can you tell me how? |
|
Confirming with |
|
Just checked and it stopped working in new folder too after VSCode restart. terraform {
required_providers {
yandex = {
source = "yandex-cloud/yandex"
version = "0.124.0"
}
ansible = {
source = "ansible/ansible"
version = "1.3.0"
}
gitlab = {
source = "gitlabhq/gitlab"
version = "~>17.1"
}
swarm = {
source = "aucloud/swarm"
version = "~> 1.2"
}
}
}
provider "yandex" {
}
provider "ansible" {
}
provider "gitlab" {
}
provider "swarm" {
} |
|
Ok, some progress! As soon as I add HTTP backend configuration autocompletions break, remove backend and everything works again. # backend.tf
terraform {
backend "http" {
address = "https://gitlab.com/api/v4/projects/<project_id>/terraform/state/production"
lock_address = "https://gitlab.com/api/v4/projects/<project_id>/terraform/state/production/lock"
unlock_address = "https://gitlab.com/api/v4/projects/<project_id>/terraform/state/production/lock"
username = "<username>"
lock_method = "POST"
unlock_method = "DELETE"
retry_wait_min = 5
}
}
|
|
Thank you for providing additional context and further digging into this issue, @Real-Gecko! Most of the completion in terraform-ls is powered by provider schemas. The schemas contain the provider configuration, data sources, and resources that a provider ships. The language server has two ways to get the schemas: bundled into the binary or via the Terraform CLI. We bundle all official and provider schemas into the binary at build time. For the four providers mentioned, this only applies to
After running
(Note also the underlined provider blocks. This indicates that we have a schema available and will show the version and a link to the documentation on hover) Once you add a backend, the Terraform CLI will error when it tries to retrieve the provider schemas. So we can't load the schemas for the other three providers and are left with the bundled gitlab schema.
Can you check the logs to see if this is happening to you? (View -> Output -> Select |
|
Hi, my logs are: That's the only error related to |
|
I've tried putting terraform {
backend "http" {
address = "https://gitlab.com/api/v4/projects/<project_id>/terraform/state/production"
lock_address = "https://gitlab.com/api/v4/projects/<project_id>/terraform/state/production/lock"
unlock_address = "https://gitlab.com/api/v4/projects/<project_id>/terraform/state/production/lock"
username = "<username>"
lock_method = "POST"
unlock_method = "DELETE"
retry_wait_min = 5
password = "<password>"
}
}And now autocompletion works, however it's not the solution, cause storing passwords in plaintext is not safe :D |
|
I figured out the primary problem I'm having: Autocomplete/intellisense doesn't work in nested keys inside objects; see my comment in this thread #1793 (comment) In those screenshots, you can see I'm trying to autocomplete Autocomplete also doesn't work inside nested HCL objects being used in resources, e.g. below: I tried multiple tests like @Real-Gecko where I changed my backed from remote S3 to local, and found that the same problem above persists across all situations; so I think we're dealing with different issues here: for me, autocomplete in all other ways than the nested issue I described above does work, for both local and remote state. I did do a system reboot since I was having the last problem and OP'd here, and I swear other autocomplete situations weren't working, but now I can't demonstrate it. I'll post again if other scenarios stop working. This is still a rather significant inconvenience, since a lot of the time we are building objects with nested keys. E.g. as above, using my various resources' and modules' attributes/outputs as values in my Thanks |
I have the same problem. For example: variable "foo" {
type = object({
value1 = string
})
}This will auto-complete "value1" as soon as I start typing "v". Furthermore, mistyping "value1" as "value11" will result in a red squiggly line, as expected. However, when we change it to use a map: variable "foo" {
type = map(object({
value1 = string
}))
}This ruins auto-complete. It also ruins type validation, meaning that I can actually mistype "value1" as "value11" and I don't get any red squiggly lines. This is kind of heartbreaking, since I am coming from a TypeScript background where this kind of thing would always be type-safe. |
Extension Version
v0.2.5EDIT v2.30.1VS Code Version
Version: 1.84.0
Commit: d037ac076cee195194f93ce6fe2bdfe2969cc82d
Date: 2023-11-01T11:28:21.782Z
Electron: 25.9.2
ElectronBuildId: 24603566
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Linux x64 6.9.3-76060903-generic
Operating System
Terraform Version
Terraform v1.6.6 on linux_amd64 + provider registry.terraform.io/alekc/kubectl v2.0.4 + provider registry.terraform.io/hashicorp/aws v5.26.0 + provider registry.terraform.io/hashicorp/helm v2.14.0 + provider registry.terraform.io/hashicorp/http v3.4.3 + provider registry.terraform.io/hashicorp/kubernetes v2.29.0 + provider registry.terraform.io/hashicorp/local v2.5.1 + provider registry.terraform.io/hashicorp/random v3.6.2 Your version of Terraform is out of date! The latest version is 1.9.2. You can update by downloading from https://www.terraform.io/downloads.html
Steps to Reproduce
Expected Behavior
Autocompletion works.
Actual Behavior
It doesn't work all (most of) the time; it does work intermittently. Syntax highlighting also doesn't work..e.g. in
aws_vpc.myresource, e.g., "myresource" will be white, not red, when the autocomplete doesn't work.Terraform Configuration
Project Structure
This is generic aws provider resources and variable declarations to produce. The project has about 5 modules in
/modulesand several modules that call those reusable modules, in/envs/*; it is not massive.No response
Gist
No response
Anything Else?
it works sometimes..I did a test on a small project with a main.tf, locals.tf, and vars.tf in one module, and autocomplete/intellisense works among the different files.
Workarounds
No response
References
No response
Help Wanted
Community Note
The text was updated successfully, but these errors were encountered: