-
Notifications
You must be signed in to change notification settings - Fork 18k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/tools/gopls: error loading workspace when go.mod is directly updated to include a new dependency #47538
Comments
I think the issue here is that the workspace is in a good state on start, so when the new dependency is added, it doesn't retry the initial workspace load. I would've expected there to be a diagnostic in the |
Another case that is affected by this is when users switch between different branches - Restarting Gopls is the current available workaround. cc @golang/tools-team |
Per https://go.dev/cl/274120, this is actually WAI. But I think it's confusing. When we reload the workspace we should allow network access. |
I think it would be nice if the gopls communicates clearly - "the requested modules (foo, bar, baz) aren't in the module cache; we need to fetch from the network to continue. Proceed? Yes : No". Or, as my original report suggested, rewrite the error message (any error message that mentions GOPROXY=off is an internal error, and it's best to hide it from users IMO) and present the |
@hyangah if the workspace needs to be fully reloaded (due to go.mod or go.sum change), I think it seems reasonable to allow network access. The original issue (#38462) was about go mod tidy diagnostics, but a full workspace reload would be far less frequent, and would correspond to user action (e.g. the save of a go.mod file). That seems to Do The Right Thing rather than introduce a dialog for the user (esp. since not all LSP clients support showMessageRequest). |
@findleyr As long as users with poor network connection wouldn't experience the problem (hang) described in https://go.dev/cl/274120 description, I think that works too. (does it mean "allowImplicitNetworkAccess" option becomes true by default?) BTW, the example #47538 (comment) is not associated with a user action happened inside editor, but file watch events triggered by the change outside of editor. |
Confirmed that this is now fixed at tip, following CL 419500. |
What version of Go/Gopls are you using (
go version
)?What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
go clean -modcache
to empty the module cache. (clean state)What did you expect to see?
The new dependency is picked up automatically.
Or gopls sends diagnostics with code actions or codelens that downloads the new dependency.
What did you see instead?
Stuck in workspace loading, without any action or helpful info to address the issue.
I found multiple ways to get out of this broken state, and would be nice if gopls suggests one of them or other:
go mod tidy
orgo get
...The following is the gopls log -
gopls log
git fetch
.This was the only diagnostic message presented in

go.mod
.Sorry that I didn't report with a simpler repro case. Probably it's easy enough (just adding a change that adds a new module to go.mod and the code) but want to check if this is a known issue.
The text was updated successfully, but these errors were encountered: