Doing anything takes forever or is impossible #3649
Comments
TheOnlyWei
changed the title
|
@TheOnlyWei I was seeing issues like this with Go in VS Code with the Go Companion extension (also tracked in this repo) installed but they stopped when I disabled it. |
|
@TheOnlyWei Thanks for the report. We need more info for triage since the repro step included in this report alone doesn't seem to reproduce the issue. Can you please follow the instruction here (https://github.com/golang/vscode-go/wiki/troubleshooting#collect-extension-logs) and
Do you mean there were merge conflicts before saving files, or you ended up facing merge conflicts due to slow saving?? Not an ideal solution, but you can try to disable the auto-import/formatting on save while we are investigating. @stevehipwell your issue may be different since the original report uses VS Code Go v0.44.0 with which Go companion extension isn't supposed to get activated. If you encountered the issue please report the problem in a separate issue so we can track it down. Thanks. |
|
@hyangah I was using the Go |
|
@TheOnlyWei Do you have Go Companion installed? @stevehipwell With Go 0.44.0 and Go Companion 0.0.5 installed, I'd expect you to end up with two separate copies of the test item tree in VSCode's testing panel. Go Companion's presence should not have an effect on normal (non-prerelease) versions of the Go extension.
Does "when I disabled it" refer to Go Companion, Go, or both? If disabling Go Companion makes the Go extension work, my guess is it has something to do with gopls, such as a crash in the test discovery code. @hyangah @findleyr does that seem plausible? Besides gopls the interaction between the two extensions is very limited. @hyangah Go Companion's activation isn't conditional, though maybe it should be. |
|
@firelizzard18 "when I disabled it" refers to Go Companion. I have the companion for the test explorer improvements, but if it's no longer required I can leave it disabled? |
|
@stevehipwell Test explorer improvements/features are being worked on in Go Companion so it's still required from that perspective. Prerelease versions of the Go extension will automatically disable the old test explorer and code lens implementation, but you're running a release version of the Go extension; if you want to avoid seeing both, you need to disable the old implementation via settings or switch to a prerelease version of the Go extension. |
|
@firelizzard18 v0.44.0 is the non-prerelease, latest version of the Go extension. Having two testing panels aren't nice (even though I don't know why users would end up with Go Companion and Go 0.44.0) and suppressing the Go companion would be nice. Looks like the gopls didn't crash (if we believe the status bar in the screenshot), but seeing the trace will help us investigate. |
|
@TheOnlyWei Can you please share the log you see in the gopls output channel when this issue is occurring? |
firelizzard18
added
the
WaitingForInfo
|
@firelizzard18 @hyangah I followed some advice to add the Go companion, but AFAIk it didn't specify using a pre-release version of the Go extension? This was all working correctly a few weeks ago. |
|
@stevehipwell I started a separate discussion because I don't want to derail this issue. |
|
@hyangah There is nothing in the By merge conflict, I mean when I save the files while the Go extension is hanging on doing stuff, it is preventing VS code from saving and would eventually detect a merge conflict with the file and pop up a split window asking you to keep one version versus some other version. However, this happened maybe several months ago, not sure if it is still an issue. Maybe the behavior changed, but I don't remember how to repro the merge conflict. @firelizzard18 I don't have Go Companion installed.
|
|
{
"[go]": {
"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
"source.organizeImports": "never"
},
// "editor.defaultFormatter": "golang.go"
},
"gopls": {
"formatting.gofumpt": true,
"ui.diagnostic.staticcheck": true
},
"go.alternateTools": {
"go": "/opt/golang1.23/go/bin/go",
},
"go.formatTool": "goimports"
}
This works for me after an initialization of around 30 seconds. |
|
I am hitting what seems like the same issue. I don't think I have any go specific custom vscode settings. I cannot save go files and in general my vscode "hover tips" for lack of a better term cease to function unless I restart the gopls server. Then things are good only for a few minutes. This is running on wsl FWIW VSCode version: go version: 1.22.7 vscode go extension version: 0.45.0 gopls version: v0.17.1 gopls (server) output during repro: view from my vscode: no tips on hover |
|
@jtcarden0001 does this occur with [email protected]? ( The good news is that the entire imports cache logic is going to disappear soon. However, 17m44 an extremely poor experience. |
|
yes, it still occurs. If there is anything else I can provide for diagnostic purposes or anything I can disable so I don't have to restart the server on every save, also, please let me know. |
|
@TheOnlyWei in your case the initial workspace load is timing out after 10m, which is why nothing works: [Info - 1:21:03 PM] 2025/01/06 13:21:03 9m59.9014992s for GOROOT= GOPATH=C:\Users\test\go GO111MODULE=auto GOPROXY=https://proxy.golang.org,direct PWD=C:\repos\myproject\myrepo go list -e -json=Name,ImportPath,Error,Dir,GoFiles,IgnoredGoFiles,IgnoredOtherFiles,CFiles,CgoFiles,CXXFiles,MFiles,HFiles,FFiles,SFiles,SwigFiles,SwigCXXFiles,SysoFiles,TestGoFiles,XTestGoFiles,CompiledGoFiles,Export,DepOnly,Imports,ImportMap,TestImports,XTestImports,ForTest,DepsErrors,Module,EmbedFiles -compiled=true -test=true -export=false -deps=true -find=false -pgo=off -- "C:\repos\myproject\myrepo\..." builtin Can you share how many files you have in that directory? (whatever "myrepo" stands for?). How long does |
|
Another potential cause of extreme slowness during the initial workspace load is cgo preprocessing, but I see you have CGO_ENABLED=0... 🤔 . |
|
@findleyr Using PowerShell, it counts 1840. I ran I tried it again and left it running for about an hour or so and it listed all of the packages, but one package was not found: Also, I can reproduce this error on two Windows 11 OS computers, but not on a Windows Server 2022 Datacenter VM. |
FWIW, this command should generally take ~seconds (or perhaps 30s for huge workspaces), not an hour. My guess is that you have a dependency that cannot be downloaded from the proxy. Are you not able to build or run your project? |
|
I'm having the same issue, adding my troubleshooting info in case it helps. For me this is a regression and I only started seeing it today.
There are two different go environments in this one repo, so I'm also attaching both. repo base-level go env
repo service-level go env
Relevant go settings: |
|
@annapankiewicz it looks like the critical section of logs may have been cut off: at the start of your log I see that gopls is already not responding to requests. Can you check to see if gopls was recently updated? ( Also, can you try running $ export GOMODCACHE=$(mktemp -d)
$ go list -test ./...
$ code .(Explanation: (1) configure an empty module cache for your environment; (2) list packages, to ensure they are downloaded; (3) start VS Code in this clean environment) |
|
agh, sorry about that!
Downgrading also resolves the issue , I reset |
|
@annapankiewicz if running in a clean module cache fixes the problem, that is a strong indication that this is related to goimports, thank you. Just to sanity check: if you reset GOMODCACHE and reinstall gopls@latest, the problem reappears? |
|
Now I feel like I need a sanity check! After resetting
repo base-level go env
repo service-level go env
|
No, I am not able to build my project since one of the modules is not found, but not sure what that has to do with Go extension constantly timing out loading workspace or never being able to go to definition of a random function or save |
|
@TheOnlyWei the relationship between these conditions is that gopls times out running (effectively) It's essentially a prerequisite for using the extension that it is able to list all packages in your workspace, or at least to fail to load some packages in a timely manner. Can you try |
I didn't measure it the first time, l just left it for about an hour or so. Measuring it shows actual run time is lower at around 2 minutes and 25 seconds. Here is the result of PowerShell The I also tried uninstalling Go 1.23.0 and installing 1.23.4, but it didn't fix anything. Is there a way to fully uninstall all files saved or installed by Go on Windows 11, and then do a fresh clean install? |
|
It was taking too long for you guys to resolve, so I tried to figure out how to get my settings at least to a working state. First, I did a full uninstall and then a clean install. After uninstalling Go 1.23.4 and VS Code Go extension 0.44.0, I discovered around These were the Go-related folders on Would be good if Golang install or uninstall web page had instructions or a process to do a full uninstall. The way it uninstalls leaves tons of cached files, causing bugs like this. I did the following to resolve the issue.
Initial experience was the Lastly, I had been using the latest version Update: I opened the project the next day after the stuff from above and the issues became worse, although it still completes as compared to initially never completing. It took about 8 minutes to load the workspace this time and save a file. |
@TheOnlyWei to be clear we want to understand and resolve this problem, but doing so is difficult without a local reproducer, and we have to balance the investigation here against other work that is ongoing. I understand that you're experiencing a horrible and frustrating failure mode, but please consider that we are a small team supporting a complex server that interacts heavily with both the operating system and build system. Based on what we know, it seems likely that the problem is related to both the operating system and build system. I hope that we can continue this investigation so that we can reach a resolution that benefits other users. From your logs, we saw that the call to Can you please run
^^The fact that loading could vary from hours to minutes to seconds is a strong signal that there is something external involved, such as a virus scanner. |
|
Likely relevant to my troubleshooting info is that I'm running VS Code from an Ubuntu VM, not on Windows. Not sure if I can help out at all but I'm happy to try! |
|
@annapankiewicz thanks, please let us know if this starts happening for you again.
Can you check to see how large that directory is, now? It's possible that the module cache was garbage collected. |
|
Added an update to my post above. I opened the project today after the stuff from above and the issues became worse, although it still completes as compared to initially never completing. It took about 8 minutes to load the workspace this time and save a file. I closed and opened the project again, then workspace loading timed out again with context exceeding deadline. However, for some reason I can save instantly, but I cannot go to definition of functions because workspace failed to load. I installed Many people at my company (Microsoft) also have this issue and seems to be able to resolve this by moving the project to WSL (ubuntu). However, some people sometimes still encounter the same issue on WSL. I switched to WSL and the issue seems to be gone. @findleyr If there is a file access issue, VS Code Go extension or Go should be collecting that in the logs, no? |
|
@TheOnlyWei can you please try running
It doesn't sound like there are access failures; it sounds like the filesystem or |
|
@findleyr For the command I ran First run for downloading (around 00:04:25): Second run with packages already downloaded (around 00:01:13). |
|
@TheOnlyWei yes, I'm trying to understand whether the performance of Once your workspace has finished its initial load, are file saves generally fast (like, ~instantaneous)? BTW, in case it is not clear, the loading state of the workspace is indicated in the status bar: |
Currently, it's 3.5GB, but I've been doing work on other branches in that repo. If I repeat that process and use the temp directory for GOMODCACHE, it's 315M prior to installing the latest, and 749M after. If the context helps, I also work at Microsoft albeit on a different team. I don't think it's completely solved by moving to Ubuntu on WS since I ran into it at first on an Ubuntu 22.04 VM. |
|
@findleyr I restarted VS Code and workspace took a long time to load but did not time out. I would guess it took around 9 minutes or less since I assume 10 minute is the timeout limit. This was with Go extension version I successfully ran I restarted VS Code again, and ran However, I checked a few minutes later in the same VS Code session, even though the workspace loading pop-up disappeared as described above, typically indicating that workspace loaded, it reappeared with context deadline timeout. So, there was some UI inconsistency. In conclusion, I don't know if workspace was loading the whole time and took the same amount of time as I can also confirm that the issue disappeared for me after switching to WSL (ubuntu), at least for now. But as mentioned before, other people encounter this issue on Linux. |
|
I have similar problems. I am using win11. I'm sure I'm just using the go extension and have configured nothing.
Every time there is a problem, I will see a lot of compile.exe under gopl.exe or a lot of compile.exe outside gopl.exe in the task manager. The maximum number of compile.exe reached 600 at one time, and it didn't get better even if I closed them all. They can only be killed manually, and they will not be killed by closing vscode. |
findleyr
removed
the
WaitingForInfo
|
@Axb12 that sounds like a misconfigured Go environment, as your |
I also get Access denied errors when I don't use vscode. I found the problem on golang side and it was caused by my antivirus software. |
|
To all: I'm going to see if I can reproduce these symptoms in a Windows environment, in particular trying to understand the huge performance gap between native Windows and WSL. I suspect that there are several distinct root causes being reported in this issue, so I'm going to focus specifically on:
This will be critical to understand. I will try to reproduce, but @TheOnlyWei if you could try running |
|
@findleyr This is the time to run There was an import cycle warning in the result that I did not see when I run the same command in Windows 11. |
|
@TheOnlyWei thank you, that is an enormous gap that explains the difference in experience.
Due to build constraints, the package graph on linux can be much different than on windows. That may also explain the difference in go list performance: perhaps the project links significantly less code when built on Linux. Could you share the equivalent of Appreciate your back-and-forth; it's very helpful in guiding the investigation. |
|
@findleyr Similar number of items, Windows 11 just took significantly longer: Windows 11 WSL |
|
I may have found a solution. Just set |
|
@Axb12 this issue is focusing on the problem of There could be many causes for the symptom of the extension hanging for a long time (and there have been many in the past that have been fixed). So while I am very curious why setting |
|
@findleyr It's strange that I can't reproduce this problem now, even if I delete the environment variables. I am currently running the |
What version of Go, VS Code & VS Code Go extension are you using?
1.23.0 1.96.2 0.44.0
go versionto get version of Go from the VS Code integrated terminal.gopls -v versionto get version of Gopls from the VS Code integrated terminal.code -vorcode-insiders -vto get version of VS Code or VS Code Insiders.Go: Locate Configured Go Toolscommand.Share the Go related settings you have added/edited
Run
Preferences: Open Settings (JSON)command to open your settings.json file.Share all the settings with the
go.or["go"]orgoplsprefixes.Describe the bug
Doing anything with the extension hangs on any of these messages:
Currently, it is impossible to develop in VS Code with Go extension that it's better to just uninstall the VS Code Go extension just so I can save. In the past, I used to get a merge conflict when saving files if you edit between when it is trying to save and before it is actually saved, but don't remember how to reproduce it and the behavior might have changed in newer versions. I can reproduce this error on two Windows 11 OS computers, but not on a Windows 10 OS VM.
I expect to be able to save my
.gofiles. There has been a bunch of these issues in the issues history, none of them have any proper resolution.Steps to reproduce the behavior:
Go to Defintion.Screenshots or recordings
The text was updated successfully, but these errors were encountered: