Doing anything takes forever or is impossible

[TheOnlyWei]

What version of Go, VS Code & VS Code Go extension are you using?

1.23.0 1.96.2 0.44.0

• Run go version to get version of Go from the VS Code integrated terminal.
  • go version go1.23.0 windows/amd64
• Run gopls -v version to get version of Gopls from the VS Code integrated terminal.
  • golang.org/x/tools/gopls v0.16.2
• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders.
  • 1.96.2
• Check your installed extensions to get the version of the VS Code Go extension
  • 0.44.0
• Run Ctrl+Shift+P (Cmd+Shift+P on Mac OS) > Go: Locate Configured Go Tools command.

# Tools Configuration


## Environment

GOBIN: undefined
toolsGopath: 
gopath: C:\Users\test\go
GOROOT: C:\Program Files\Go
PATH: C:\Program Files\Eclipse Adoptium\jdk-21.0.3.9-hotspot\bin;C:\Program Files\Microsoft SDKs\Azure\CLI2\wbin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\nodejs\;C:\Program Files\Microsoft SQL Server\150\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\ProgramData\chocolatey\bin;C:\Program Files\Go\bin;C:\Program Files\PowerShell\7\;C:\Program Files\dotnet\;C:\Program Files\Git\cmd;C:\Program Files\Docker\Docker\resources\bin;C:\Users\test\AppData\Local\Programs\Python\Python311\Scripts\;C:\Users\test\AppData\Local\Programs\Python\Python311\;C:\Users\test\AppData\Local\Microsoft\WindowsApps;C:\Users\test\AppData\Local\Programs\Microsoft VS Code\bin;C:\agents-manager;C:\Users\test\go\bin;C:\nuget;C:\Program Files\Git\mingw64\bin;C:\Users\test\.azure\kubectl-client;C:\Users\test\.azure-kubelogin;C:\Program Files\Task\task_windows_amd64;C:\Users\test\AppData\Roaming\npm;C:\Users\test\.dotnet\tools;C:\azwi\azwi-v1.3.0-windows-amd64;C:\kubectl-tools;C:\Users\test\.krew\bin;C:\Users\test\go\bin;C:\Users\test\AppData\Local\Microsoft\WindowsApps;

## Tools

	go:	C:\Program Files\Go\bin\go.exe: go version go1.23.0 windows/amd64

	gopls:	C:\Users\test\go\bin\gopls.exe	(version: v0.17.1 built with go: go1.23.4)
	gotests:	C:\Users\test\go\bin\gotests.exe	(version: v1.6.0 built with go: go1.23.0)
	gomodifytags:	not installed
	impl:	not installed
	goplay:	not installed
	dlv:	C:\Users\test\go\bin\dlv.exe	(version: v1.24.0 built with go: go1.23.0)
	staticcheck:	C:\Users\test\go\bin\staticcheck.exe	(version: v0.5.1 built with go: go1.23.0)

## Go env

Workspace Folder (myrepo): c:\repos\myproject\myrepo

	set GO111MODULE=
	set GOARCH=amd64
	set GOBIN=
	set GOCACHE=C:\Users\test\AppData\Local\go-build
	set GOENV=C:\Users\test\AppData\Roaming\go\env
	set GOEXE=.exe
	set GOEXPERIMENT=
	set GOFLAGS=
	set GOHOSTARCH=amd64
	set GOHOSTOS=windows
	set GOINSECURE=
	set GOMODCACHE=C:\Users\test\go\pkg\mod
	set GONOPROXY=
	set GONOSUMDB=
	set GOOS=windows
	set GOPATH=C:\Users\test\go
	set GOPRIVATE=
	set GOPROXY=https://proxy.golang.org,direct
	set GOROOT=C:\Program Files\Go
	set GOSUMDB=sum.golang.org
	set GOTMPDIR=
	set GOTOOLCHAIN=auto
	set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
	set GOVCS=
	set GOVERSION=go1.23.0
	set GODEBUG=
	set GOTELEMETRY=local
	set GOTELEMETRYDIR=C:\Users\test\AppData\Roaming\go\telemetry
	set GCCGO=gccgo
	set GOAMD64=v1
	set AR=ar
	set CC=gcc
	set CXX=g++
	set CGO_ENABLED=0
	set GOMOD=c:\repos\myproject\myrepo\go.mod
	set GOWORK=
	set CGO_CFLAGS=-O2 -g
	set CGO_CPPFLAGS=
	set CGO_CXXFLAGS=-O2 -g
	set CGO_FFLAGS=-O2 -g
	set CGO_LDFLAGS=-O2 -g
	set PKG_CONFIG=pkg-config
	set GOGCCFLAGS=-m64 -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\test\AppData\Local\Temp\go-build3413711034=/tmp/go-build -gno-record-gcc-switches

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"] or gopls prefixes.

    "go.toolsManagement.autoUpdate": true,
    "go.languageServerFlags": [

        "-rpc.trace"
    ],
    "gopls": {
        "verboseOutput": true
    }

Describe the bug

Doing anything with the extension hangs on any of these messages:

Getting code actions from 'Go' ([configure](command:workbench.action.openSettings?%5B%22editor.codeActionsOnSave%22%5D)).
Saving 'bicep.go': Running Code Actions and Formatters...
Setting up workspace: Loading packages...

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 .go files. There has been a bunch of these issues in the issues history, none of them have any proper resolution.

Steps to reproduce the behavior:

1. Install VS Code Go extension.
2. Edit a .go file.
3. Try to save the .go file.
4. Right click a random function and click Go to Defintion.
5. Go extension tries to do a bunch of things that never ends up being done and file is never saved.

Screenshots or recordings

[stevehipwell]

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

[hyangah]

@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 share the log? (We want to understand why "loading workspace" couldn't complete so we need log messages around workspace loading)

Otherwise, there is a merge conflict when saving files if you edit between when it is trying to save and before it is actually saved.

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.

      "[go]": {
        "editor.formatOnSave": false,
        "editor.codeActionsOnSave": {
          "source.organizeImports": "never"
        }
      }

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

[stevehipwell]

@hyangah I was using the Go 0.44.0 extension and the Go Companion 0.0.5 extension and AFAIK both were active.

[firelizzard18]

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

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.

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.

[stevehipwell]

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

[firelizzard18]

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

[hyangah]

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

[firelizzard18]

@TheOnlyWei Can you please share the log you see in the gopls output channel when this issue is occurring?

[stevehipwell]

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

[firelizzard18]

@stevehipwell I started a separate discussion because I don't want to derail this issue.

[TheOnlyWei]

@hyangah There is nothing in the Tasks output.

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.

gopls (server) output log: gopls_server.txt

Extension Host extension_host.txt

Developer Tools developer_tools.txt

[jinbangyi]

.vscode/settings.json

{
  "[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.

[jtcarden0001]

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: 1.96.2 fabdb6a30b49f79a7aba0f2ad9df9b399473380f x64

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: notification hanging while trying to save

no tips on hover

[findleyr]

@jtcarden0001 does this occur with [email protected]? (go install golang.org/x/tools/[email protected]).

The good news is that the entire imports cache logic is going to disappear soon. However, 17m44 an extremely poor experience.

[jtcarden0001]

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.

[findleyr]

@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 go list ./... take from that directory?

[findleyr]

Another potential cause of extreme slowness during the initial workspace load is cgo preprocessing, but I see you have CGO_ENABLED=0... 🤔 .

[TheOnlyWei]

@findleyr Using PowerShell, it counts 1840.

Write-Host ( Get-ChildItem "C:\repos\myproject\myrepo" -Recurse | Measure-Object ).Count
1840

I ran go list ./..., but seems to be stuck for more than 20 minutes with the below output before I exited.

go list ./...
go: downloading github.com/microsoft/mochost-sdk-for-go v0.11.1-alpha.1

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:

pkg\cloud\cloud\hostagent\service_windows.go:13:2: reading github.com/microsoft/mochost-sdk-for-go/go.mod at revision v0.11.1-alpha.1: git ls-remote -q origin in C:\Users\test\go\pkg\mod\cache\vcs\5b47955b4ed7c730e2e673d13f3d638f26e38811b5e85462bccf788f3d272547: exit status 128:
        remote: Repository not found.
        fatal: repository 'https://github.com/microsoft/mochost-sdk-for-go/' not found
pkg\aks\template\bicep\bicep.go:9:2: github.com/microsoft/[email protected]: reading github.com/microsoft/mochost-sdk-for-go/go.mod at revision v0.11.1-alpha.1: git ls-remote -q origin in C:\Users\test\go\pkg\mod\cache\vcs\5b47955b4ed7c730e2e673d13f3d638f26e38811b5e85462bccf788f3d272547: exit status 128:
        remote: Repository not found.
        fatal: repository 'https://github.com/microsoft/mochost-sdk-for-go/' not found

Also, I can reproduce this error on two Windows 11 OS computers, but not on a Windows Server 2022 Datacenter VM.

[findleyr]

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:

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?

[annapankiewicz]

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.

anna@myVm:~/clones/repo$ go version
go version go1.23.1 linux/amd64
anna@myVm:~/clones/repo$ gopls -v version
Build info
----------
golang.org/x/tools/gopls v0.17.1
    golang.org/x/tools/[email protected] h1:Mt/DSfnnSe3dyf6MH/dZZ0iww+viHNhAFc4rEYDiOAw=
    github.com/BurntSushi/[email protected] h1:pxW6RcqyfI9/kWtOwnv/G+AzdKuy2ZrqINhenH4HyNs=
    github.com/google/[email protected] h1:ofyhxvXcZhMsU5ulbFiLKl/XBFqE1GSq7atu8tAmTRI=
    golang.org/x/exp/[email protected] h1:1P7xPZEwZMoBoz0Yze5Nx2/4pxj6nw9ZqHWXqP0iRgQ=
    golang.org/x/[email protected] h1:D4nJWe9zXqHOmWqj4VMOJhvzj7bEZg4wEYa759z1pH4=
    golang.org/x/[email protected] h1:fEo0HyrW1GIgZdpbhCRO0PkJajUS5H9IFUztCgEo2jQ=
    golang.org/x/[email protected] h1:TCDqnvbBsFapViksHcHySl/sW4+rTGNIAoJJesHRuMM=
    golang.org/x/[email protected] h1:gK/Kv2otX8gz+wn7Rmb3vT96ZwuoxnQlY+HlJVj7Qug=
    golang.org/x/[email protected] h1:kgwdasJRsdDWYgWcEgMF424DiXwwXHSb3V8xVTi//i8=
    golang.org/x/[email protected] h1:SP0mPeg2PmGCu03V+61EcQiOjmpri2XijexKdzv8Z1I=
    honnef.co/go/[email protected] h1:4bH5o3b5ZULQ4UrBmP+63W9r7qIkqJClEA9ko5YKx+I=
    mvdan.cc/[email protected] h1:bg91ttqXmi9y2xawvkuMXyvAA/1ZGJqYAEGjXuP0JXU=
    mvdan.cc/xurls/[email protected] h1:lyBNOm8Wo71UknhUs4QTFUNNMyxy2JEIaKKo0RWOh+8=
go: go1.23.4
anna@myVm:~/clones/repo$ code -v
1.96.3
91fbdddc47bc9c09064bf7acf133d22631cbf083
x64
anna@myVm:~/clones/repo$

There are two different go environments in this one repo, so I'm also attaching both.

repo base-level go env

anna@myVm:~/clones/repo$ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/anna/.cache/go-build'
GOENV='/home/anna/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/anna/go/pkg/mod'
GONOPROXY='dev.azure.com'
GONOSUMDB='dev.azure.com'
GOOS='linux'
GOPATH='/home/anna/go'
GOPRIVATE='dev.azure.com'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/anna/go/pkg/mod/golang.org/[email protected]'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/anna/go/pkg/mod/golang.org/[email protected]/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.1'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/anna/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/anna/clones/repo/go.mod'
GOWORK='/home/anna/clones/repo/go.work'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build524703250=/tmp/go-build -gno-record-gcc-switches'

repo service-level go env

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/anna/.cache/go-build'
GOENV='/home/anna/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/anna/go/pkg/mod'
GONOPROXY='dev.azure.com'
GONOSUMDB='dev.azure.com'
GOOS='linux'
GOPATH='/home/anna/go'
GOPRIVATE='dev.azure.com'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/anna/go/pkg/mod/golang.org/[email protected]'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/anna/go/pkg/mod/golang.org/[email protected]/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.1'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/anna/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/anna/clones/repo/services/service/server/go.mod'
GOWORK='/home/anna/clones/repo/go.work'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3043638905=/tmp/go-build -gno-record-gcc-switches'

Relevant go settings:

"go.toolsManagement.autoUpdate": true,
"go.languageServerFlags": [
    "-rpc.trace"
],
"gopls": {
    "verboseOutput": true
},

gopls log.txt

[findleyr]

@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? (ls -l $(which gopls)) If so, can you try downgrading to [email protected]? (go install golang.org/x/tools/[email protected]) to see if it resolves the problem?

Also, can you try running go list ./... from your workspace to ensure that is fast? And finally, can you try running gopls in a clean module cache, to see if that solves the problem?

$ 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)

[annapankiewicz]

agh, sorry about that! I did try updating it earlier today with go install golang.org/x/tools/gopls@latest based off another, older GitHub issue I found. Unfortunately I don't know what version I had right before trying that.

anna@myVm:~/clones/repo$ ls -l $(which gopls)
-rwxrwxr-x 1 anna anna 34062231 Jan 14 19:14 /home/anna/go/bin/gopls

go list ./... is not immediate, but takes less than 20-30 seconds. Running gopls in a clean module cache like you suggested does work in about the same amount of time, and opening a new VS code instance from there doesn't have the problem.

Downgrading also resolves the issue , I reset GOMODCACHE to $GOPATH/pkg/mod before doing that.

[findleyr]

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

[annapankiewicz]

Now I feel like I need a sanity check! After resetting export GOMODCACHE=$GOPATH/pkg/mod and installing the latest, it now doesn't happen. I'm including the troubleshooting details from this current setup, I can't see anything immediately "off" between this and the unsuccessful try.

anna@myVm:~/clones/repo$ go version
go version go1.23.1 linux/amd64
anna@myVm:~/clones/repo$ gopls -v version
Build info
----------
golang.org/x/tools/gopls v0.17.1
    golang.org/x/tools/[email protected] h1:Mt/DSfnnSe3dyf6MH/dZZ0iww+viHNhAFc4rEYDiOAw=
    github.com/BurntSushi/[email protected] h1:pxW6RcqyfI9/kWtOwnv/G+AzdKuy2ZrqINhenH4HyNs=
    github.com/google/[email protected] h1:ofyhxvXcZhMsU5ulbFiLKl/XBFqE1GSq7atu8tAmTRI=
    golang.org/x/exp/[email protected] h1:1P7xPZEwZMoBoz0Yze5Nx2/4pxj6nw9ZqHWXqP0iRgQ=
    golang.org/x/[email protected] h1:D4nJWe9zXqHOmWqj4VMOJhvzj7bEZg4wEYa759z1pH4=
    golang.org/x/[email protected] h1:fEo0HyrW1GIgZdpbhCRO0PkJajUS5H9IFUztCgEo2jQ=
    golang.org/x/[email protected] h1:TCDqnvbBsFapViksHcHySl/sW4+rTGNIAoJJesHRuMM=
    golang.org/x/[email protected] h1:gK/Kv2otX8gz+wn7Rmb3vT96ZwuoxnQlY+HlJVj7Qug=
    golang.org/x/[email protected] h1:kgwdasJRsdDWYgWcEgMF424DiXwwXHSb3V8xVTi//i8=
    golang.org/x/[email protected] h1:SP0mPeg2PmGCu03V+61EcQiOjmpri2XijexKdzv8Z1I=
    honnef.co/go/[email protected] h1:4bH5o3b5ZULQ4UrBmP+63W9r7qIkqJClEA9ko5YKx+I=
    mvdan.cc/[email protected] h1:bg91ttqXmi9y2xawvkuMXyvAA/1ZGJqYAEGjXuP0JXU=
    mvdan.cc/xurls/[email protected] h1:lyBNOm8Wo71UknhUs4QTFUNNMyxy2JEIaKKo0RWOh+8=
go: go1.23.4
anna@myVm:~/clones/repo$ code -v 
1.96.3
91fbdddc47bc9c09064bf7acf133d22631cbf083
x64

repo base-level go env

anna@myVm:~/clones/repo$ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/anna/.cache/go-build'
GOENV='/home/anna/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/anna/go/pkg/mod'
GONOPROXY='dev.azure.com'
GONOSUMDB='dev.azure.com'
GOOS='linux'
GOPATH='/home/anna/go'
GOPRIVATE='dev.azure.com'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/anna/go/pkg/mod/golang.org/[email protected]'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/anna/go/pkg/mod/golang.org/[email protected]/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.1'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/anna/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/anna/clones/repo/go.mod'
GOWORK='/home/anna/clones/repo/go.work'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3913303627=/tmp/go-build -gno-record-gcc-switches'

repo service-level go env

anna@myVm:~/clones/repo/services/service$ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/anna/.cache/go-build'
GOENV='/home/anna/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/anna/go/pkg/mod'
GONOPROXY='dev.azure.com'
GONOSUMDB='dev.azure.com'
GOOS='linux'
GOPATH='/home/anna/go'
GOPRIVATE='dev.azure.com'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/anna/go/pkg/mod/golang.org/[email protected]'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/anna/go/pkg/mod/golang.org/[email protected]/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.1'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/anna/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/anna/clones/repo/go.mod'
GOWORK='/home/anna/clones/repo/go.work'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3718337942=/tmp/go-build -gno-record-gcc-switches'

[TheOnlyWei]

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:

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?

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 .go files.

[findleyr]

@TheOnlyWei the relationship between these conditions is that gopls times out running (effectively) go list ./... in your workspace, as the initial workspace load has a timeout of 10m.

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 go list -x ./... to see what is taking so long?

[TheOnlyWei]

@TheOnlyWei the relationship between these conditions is that gopls times out running (effectively) go list ./... in your workspace, as the initial workspace load has a timeout of 10m.

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 go list -x ./... to see what is taking so long?

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 Measure-Command {go list -x ./...}. So, it doesn't feel like this is causing workspace loading to exceed context deadline, never being able to go to definition of a random function, or save .go files. In the same session of VS Code that I ran this command, I had the Error loading workspace: context deadline exceeded issue.

The microsoft/mochost-sdk-for-go errors are as is expected, I just need to configure my access to the repository. But not sure how that affects the Go extension.

go: downloading github.com/microsoft/mochost-sdk-for-go v0.11.1-alpha.1
# get https://proxy.golang.org/github.com/microsoft/mochost-sdk-for-go/@v/v0.11.1-alpha.1.zip
# get https://proxy.golang.org/github.com/microsoft/mochost-sdk-for-go/@v/v0.11.1-alpha.1.zip: 404 Not Found (0.112s)
mkdir -p C:\Users\test\go\pkg\mod\cache\vcs # git3 https://github.com/microsoft/mochost-sdk-for-go
# lock C:\Users\test\go\pkg\mod\cache\vcs\5b47955b4ed7c730e2e673d13f3d638f26e38811b5e85462bccf788f3d272547.lock
# C:\Users\test\go\pkg\mod\cache\vcs\5b47955b4ed7c730e2e673d13f3d638f26e38811b5e85462bccf788f3d272547 for git3 https://github.com/microsoft/mochost-sdk-for-go
cd C:\Users\test\go\pkg\mod\cache\vcs\5b47955b4ed7c730e2e673d13f3d638f26e38811b5e85462bccf788f3d272547; git tag -l
0.065s # cd C:\Users\test\go\pkg\mod\cache\vcs\5b47955b4ed7c730e2e673d13f3d638f26e38811b5e85462bccf788f3d272547; git tag -l
cd C:\Users\test\go\pkg\mod\cache\vcs\5b47955b4ed7c730e2e673d13f3d638f26e38811b5e85462bccf788f3d272547; git ls-remote -q origin
1.285s # cd C:\Users\test\go\pkg\mod\cache\vcs\5b47955b4ed7c730e2e673d13f3d638f26e38811b5e85462bccf788f3d272547; git ls-remote -q origin
# get https://github.com/microsoft/mochost-sdk-for-go
# get https://github.com/microsoft/mochost-sdk-for-go: 404 Not Found (0.277s)
# get https://proxy.golang.org/github.com/microsoft/mochost-sdk-for-go/@v/v0.11.1-alpha.1.mod
# get https://proxy.golang.org/github.com/microsoft/mochost-sdk-for-go/@v/v0.11.1-alpha.1.mod: 404 Not Found (0.084s)
cd C:\repos\myproject\myrepo
git status --porcelain
cd C:\repos\myproject\myrepo
git -c log.showsignature=false log -1 --format=%H:%ct
pkg\cloud\cloud\hostagent\service_windows.go:13:2: reading github.com/microsoft/mochost-sdk-for-go/go.mod at revision v0.11.1-alpha.1: git ls-remote -q origin in C:\Users\test\go\pkg\mod\cache\vcs\5b47955b4ed7c730e2e673d13f3d638f26e38811b5e85462bccf788f3d272547: exit status 128:
        remote: Repository not found.
        fatal: repository 'https://github.com/microsoft/mochost-sdk-for-go/' not found

Days              : 0
Hours             : 0
Minutes           : 2
Seconds           : 24
Milliseconds      : 966
Ticks             : 1449668464
TotalDays         : 0.00167785701851852
TotalHours        : 0.0402685684444444
TotalMinutes      : 2.41611410666667
TotalSeconds      : 144.9668464
TotalMilliseconds : 144966.8464

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?

[TheOnlyWei]

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 8,799 megabytes of files left over by Go, meaning uninstalling Go from the Windows 11 Control Panel doesn't really uninstall much of anything.

These were the Go-related folders on Windows 11 that I had to manually find and delete:

C:\Users\test\go 7,655,277Kb
C:\Users\test\AppData\Local\go-build 1,078,455Kb
C:\Users\test\AppData\Local\gopls 64,877Kb
C:\Users\test\AppData\Roaming\go 351Kb
C:\Users\test\AppData\Roaming\gopls 1Kb
Total: 8,798,961Kb

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.

1. Uninstalled VS Code Go extension, then uninstalled Go from the Control Panel.
2. Deleted all of the folders mentioned above.
3. Restarted the computer.
4. Installed Go 1.23.4.
5. Opened VS Code and entered CTRL+SHIFT+P, selected Go:Install/Update Tools, then selected gopls and dlv and clicked OK.
6. Go to OUTPUT tab of the terminal and wait for gopls and dlv to install. Sometimes it doesn't actually install properly for some reason, so make sure they are installed.

Initial experience was the Error loading workspace: context deadline exceeded issue seems to have subsided and it finished loading in seconds. I have also experienced instantly saving files and being able to go to the definition of functions instantly. However, from time to time, it still takes a long time to load the workspace, save, or go to the definition. But as time goes on, maybe 1/10 times I can manage to save a file and etc. This is a somewhat improvement from never being able to do anything from before. It also only happens to the particular repository with 1840 items since I don't get these problems with a brand new go project with a main.go with just a main function and a simple go.mod file.

Lastly, I had been using the latest version 0.44.0. I tried downgrading VS Code Go extension to a version from 0.40.x, but that didn't improve anything. Then, I downgraded further to v0.39.1 and things are working more consistently better so far. So, whatever this horrible bug you guys introduced likely occurred after 0.39.1.

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.

[findleyr]

It was taking too long for you guys to resolve So, whatever this horrible bug you guys introduced likely occurred after 0.39.1

@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 go list ./... was timing out at 10m. That is related to the go command, and so would not be directly affected by the VS Code or gopls version. I'm therefore surprised that VS Code v0.39.1 seems to improve anything -- perhaps this is just a coincidence.

Can you please run go list -compiled -test ./... now, to see if it is noticeably faster than before? If it is, that may be a sign that performance problems are related to go list caching, or perhaps to virus scanners. Either of those could potentially have been fixed by your purging of the cache(s).

Issue seems to have subsided and it finished loading in seconds.

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

[annapankiewicz]

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!