x/tools/gopls: workspace loading notifications can get stuck

[osiewicz]

Go version

go version go1.23.2 darwin/arm64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/hiro/Library/Caches/go-build'
GOENV='/Users/hiro/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/hiro/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/hiro/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.23.2/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.23.2/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.23.2'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/hiro/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOARM64='v8.0'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/Users/hiro/Projects/language_repositories/golang/juju/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/nl/9fwvt1l153v1sb0fsd0sn4840000gn/T/go-build3044280324=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

Recently Zed stopped sending out any workspaceFolders in it's Initialize request, instead opting to fill them out when a project root is discovered. We still fill out rootUri.

What did you see happen?

Our Preview users noticed that there's now a stale notification for "Setting up workspace: Loading packages...". I dug a bit into gopls sources and it looks like it fills out workspace folders with rootUri when there are no workspace folders in initialize request: https://github.com/golang/tools/blob/5dc980c6debffbe1b319cf554f28eaf100b9fc94/gopls/internal/server/general.go#L98

I think the problem here might be that later on we send out a didChangeWorkspaceFolders notification with that same folder, which might lead to the progress token not being cancelled.

When rootUri is not present in initialization params the issue goes away.

What did you expect to see?

I expected second workspace scan to not be started if there's already (implictily registered) workspace folder of the same path.

[gabyhelp]

Related Issues

• x/tools/gopls: vscode take minutes to load packages before completion becomes available #69743 (closed)
• x/tools/gopls: Workspace never comes up (no response to workspace/configuration) #41976 (closed)
• x/tools/imports: should not scan bazel-out directories #35914
• x/tools/gopls: expands workspace to the wrong root when go.mod file is above go.work. #63917 (closed)
• x/tools/gopls: file paths in symlinked dirs not resolved when running remote-mode #51825 (closed)
• x/tools/gopls: stuck on "Setting up workspace: Loading packages..." #42255 (closed)
• x/tools/gopls: misleading error message when having multiple workspace folders and using build tag #60776 (closed)
• x/tools/gopls: stuck in loading workspace #47693 (closed)
• x/tools/gopls/internal/regtest/workspace: TestOldGoNotification_Fake failures #56200 (closed)
• x/tools/gopls: long initial workspace load durations for workspace with many packages #69523

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[findleyr]

Thanks very much for this report. This sounds like a plausible bug, we'll fix for gopls@v0.18.2.

[gopherbot]

Change https://go.dev/cl/663295 mentions this issue: gopls/internal/server: workspace: skip adding already added file

[xieyuschen]

I reproduced this issue in my mac, but I cannot produce it in linux running inside VM. Here is the debug log and my gopls setting in zed.

  "lsp": {
    "gopls": {
      "binary": {
        "path": "/Users/yuchen.xie/go/bin/gopls",
        "arguments": [
          "serve",
          "-logfile=/Users/yuchen.xie/workspace/CD/goplayground/gopls.log",
          "-rpc.trace"
        ]
      }
    }
  }

gopls.log