x/tools/gopls: reinitialize the workspace if the module directive changes

[josharian]

I am working to eliminate a fork. The fork includes a change to the module import path. As a consequence, when I change git branches, the module import path changes. This causes gopls to be unable to load the workspace, and as a consequence nothing else works. (This includes saving my document without having to use my mouse to click a Cancel button and not having gofmt run). Once gopls is in this state, the only way I have found to recover is to restart VSCode.

Sample error message:

Error loading workspace: source error list: file:///Users/josh/t/wireguard-go/go.mod:0:0-0:33: go [-e -json -compiled=true -test=true -export=false -deps=true -find=false -- golang.zx2c4.com/wireguard golang.zx2c4.com/wireguard/device]: exit status 1: go: finding module for package github.com/tailscale/wireguard-go/ipc go: finding module for package github.com/tailscale/wireguard-go/wgcfg go: found github.com/tailscale/wireguard-go/ipc in github.com/tailscale/wireguard-go v0.0.20201118 go: golang.zx2c4.com/wireguard/device imports github.com/tailscale/wireguard-go/ipc: github.com/tailscale/wireguard-go@v0.0.20201118: parsing go.mod: module declares its path as: golang.zx2c4.com/wireguard but was required as: github.com/tailscale/wireguard-go

[stamblerre]

Thanks for the report. We should treat a change to the module directive as something that forces a workspace reinitialization.

[stamblerre]

@josharian: Can you share a repro case if you have one available? I saw you mentioned that you had one in your other issue.

[heschi]

I don't understand precisely what happened here. I suppose a module, possibly a replace target, was renamed from github.com/tailscale to golang.zx2c4.com, and we still knew about old name, so tried to load it? And then it's a fork, so it causes a load failure without a replace?

If I had to guess it's because we failed to clear out workspace packages when the module name changed. But I'm really not sure.

Error loading workspace: source error list: file:///Users/josh/t/wireguard-go/go.mod:0:0-0:33:
go [-e -json -compiled=true -test=true -export=false -deps=true -find=false -- golang.zx2c4.com/wireguard golang.zx2c4.com/wireguard/device]:
exit status 1:
go: finding module for package github.com/tailscale/wireguard-go/ipc
go: finding module for package github.com/tailscale/wireguard-go/wgcfg
go: found github.com/tailscale/wireguard-go/ipc in github.com/tailscale/wireguard-go v0.0.20201118
go: golang.zx2c4.com/wireguard/device imports github.com/tailscale/wireguard-go/ipc:
    github.com/tailscale/wireguard-go@v0.0.20201118: parsing go.mod: module declares its path as: golang.zx2c4.com/wireguard but was required as: github.com/tailscale/wireguard-go

[josharian]

github.com/josharian/gopls-bug was what I wrote—change back and forth between the two commits. It doesn’t reproduce as easily in a small repo. You could also try GitHub.com/Tailscale/wireguard-go and switch back and forth between main and master branches.

[stamblerre]

Thanks for the report. Was this the first time you had downloaded that repo and switched between those branches?

I see two issues here:

(1) The one @heschik described above--the module path change should cause us to delete workspace packages. (2) After running go clean -modcache and switching between the two branches, I encountered:

[Trace - 00:57:26.984 AM] Received notification '$/progress'.
Params: {"token":"8674665223082153551","value":{"kind":"begin","title":"Error loading workspace","message":"go [-e -json -compiled=true -test=true -export=false -deps=true -find=false -- github.com/tailscale/wireguard-go github.com/tailscale/wireguard-go/conn github.com/tailscale/wireguard-go/device github.com/tailscale/wireguard-go/device/tokenbucket github.com/tailscale/wireguard-go/ipc github.com/tailscale/wireguard-go/ipc/winpipe github.com/tailscale/wireguard-go/ratelimiter github.com/tailscale/wireguard-go/replay github.com/tailscale/wireguard-go/rwcancel github.com/tailscale/wireguard-go/tai64n github.com/tailscale/wireguard-go/tun github.com/tailscale/wireguard-go/tun/tuntest github.com/tailscale/wireguard-go/tun/wintun/iphlpapi github.com/tailscale/wireguard-go/tun/wintun/namespaceapi github.com/tailscale/wireguard-go/tun/wintun/nci github.com/tailscale/wireguard-go/tun/wintun/registry github.com/tailscale/wireguard-go/tun/wintun/setupapi github.com/tailscale/wireguard-go/wgcfg]: exit status 1: go: golang.org/x/crypto@v0.0.0-20201124201722-c8d3bf9c5392: module lookup disabled by GOPROXY=off "}}

GOPROXY was set to off because it wasn't our first workspace load, but a branch change should probably be treated like a reinitialization. Unfortunately, we don't have a way of determining that the user has changed branches.

[josharian]

Was this the first time you had downloaded that repo and switched between those branches?

No, this has been happening for a while.

[stamblerre]

Removing this from the gopls/v0.6.2 milestone because it raises issues closely related to https://github.com/golang/go/issues/43305 and https://github.com/golang/go/issues/42266. If we invalidate workspace packages when the module directive changes, but reinitialization only happens when the go.mod file is saved, we will have effectively invalidated the metadata by clearing out all of the workspace package paths without reloading.

This probably means that we should consider the workspacePackages map as part of "metadata" and also mark workspace packages invalid without deleting them, and then only delete them when metadata is fully invalidated on file save.

/cc @findleyr

[wu0407]

if vscode reload windows, get the errors:

[Trace - 13:09:12.290 PM] Received notification 'window/logMessage'.
Params: {"type":1,"message":"2021/03/29 13:09:12 diagnosing go.mod: err: exit status 1: stderr: go: downloading github.com/stretchr/testify v1.2.2\ngithub.com/opencontainers/runc imports\n\tgithub.com/sirupsen/logrus tested by\n\tgithub.com/sirupsen/logrus.test imports\n\tgithub.com/stretchr/testify/assert: module lookup disabled by GOPROXY=off\ngithub.com/opencontainers/runc imports\n\tgithub.com/sirupsen/logrus tested by\n\tgithub.com/sirupsen/logrus.test imports\n\tgithub.com/stretchr/testify/require: module lookup disabled by GOPROXY=off\n\n"}

why GOPROXY set off, that lead downloading module failed.

[Info  - 下午1:14:23] 2021/03/29 13:14:23 go env for D:\git\runc
(root D:\git\runc)
(go version go version go1.16 windows/amd64)
(valid build configuration = true)
(build flags: [-tags=linux])
GOPRIVATE=
GOFLAGS=
GOSUMDB=sum.golang.org
GOPROXY=https://goproxy.cn,direct
GOROOT=C:\Program Files\Go
GOPATH=D:\go
GOMOD=D:\git\runc\go.mod
GONOSUMDB=
GO111MODULE=on
GOMODCACHE=D:\go\pkg\mod
GONOPROXY=
GOCACHE=C:\Users\xiaoqing\AppData\Local\go-build
GOINSECURE=

[stamblerre]

@wu0407: Can you please open a new issue and share your gopls logs? Information on how to capture them can be found here.

[wu0407]

I manual download github.com/stretchr/testify, so can not reproduce.

[lucianjon]

@stamblerre I've been getting the same issue lately with gopls-v0.6.9, basically whenever you enter a project with a new or updated dependency it fails with the same error @wu0407 is getting. Fixing it is the same process too, manually running go get on the command line. Could be related but I also set GOPROXY to an internal proxy we use for our private dependencies.

It should be fairly easy to reproduce as I imagine I can just remove a needed dependency from the local cache to trigger it. Will try get some more details and create an issue.

EDIT: Actually looks like it may have just been the Transitive Dependencies issue. So far I can't reproduce it on gopls v0.6.10.

[tsu1980]

I think we can fix as below to disables GOPROXY=off.

"gopls": {
  "build.allowImplicitNetworkAccess": true
}

https://github.com/golang/tools/blob/master/gopls/doc/settings.md#allowimplicitnetworkaccess-bool

[gopherbot]

Change https://go.dev/cl/420956 mentions this issue: internal/lsp/cache: invalid packages should not be workspace packages