Saving is very slow because waiting for "Quick Fixes" [flaky]

[broady]

Issue Type: Bug

1. Attempt to save a file
2. See a window pop up "Running Save Participants... Quick Fixes"

Observe:
Quick Fixes doesn't complete (sometimes, this seems flaky)
Can't find anything relevant in the Go extension output

Extension version: 0.13.0
VS Code version: Code 1.42.1 (c47d83b293181d9be64f27ff093689e8e7aed054, 2020-02-11T14:44:27.652Z)
OS version: Darwin x64 18.7.0
Remote OS version: Linux x64 5.2.17-1rodete3-amd64

System Info

Item	Value
CPUs	Intel(R) Xeon(R) W-2140B CPU @ 3.20GHz (16 x 3200)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: disabled_off protected_video_decode: unavailable_off rasterization: enabled skia_renderer: disabled_off surface_control: disabled_off surface_synchronization: enabled_on video_decode: enabled viz_display_compositor: enabled_on viz_hit_test_surface_layer: disabled_off webgl: enabled webgl2: enabled
Load (avg)	1, 1, 2
Memory (System)	64.00GB (36.30GB free)
Process Argv
Screen Reader	no
VM	0%

Item	Value
Remote	SSH: cbro.mtv.corp.google.com
OS	Linux x64 5.2.17-1rodete3-amd64
CPUs	Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz (6 x 2299)
Memory (System)	11.73GB (0.14GB free)
VM	0%

[broady]

Looks like it does complete eventually (~20 seconds)

[hyangah]

This is a variation of the issue discussed in #90851 and many more. VS Code 1.42 dropped the cancellation-based approach https://code.visualstudio.com/updates/v1_42#_handling-slow-save-operations and which made this problem more visible.

This may be due to slow gopls. Or, this may be due to unknown issues in the vscode-languageclient side.

microsoft/vscode#90851 (comment) shows how to enable and capture more logging. Can you try it so we have a bit more info on what's going on? Thanks!

• F1 > Set Log Level > Trace
• Output > Log (Extension Host)

[broady]

OK, log levels increased. When saving is slow again (it's fast right now) I'll add the logs here.

[wkalt]

I started experiencing these symptoms after upgrading to 42.1 this morning. Downgrading to 41.1 seems to have resolved it for me.

Version: 1.41.1
Commit: 26076a4de974ead31f97692a0d32f90d735645c0
Date: 2019-12-18T15:04:31.999Z
Electron: 6.1.5
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Linux x64 4.15.0-88-generic

Edit: sorry, seems like this is clear from the note about 42.1 above.

[migmartri]

Same problem here. After downgrading to 41.1 I can at least save files but the Golang support does not seem to be working in fairly big projects neither.

Also using Linux.

[migmartri]

It might be a coincidence, some background indexing might have finished, but just in case this helps somebody else, this is what I did and seems to work.

1 - Disable "use language server" in vscode GO extension
2 - Restart vscode
3 - Enable it again
4 - Restart vscode

[stamblerre]

I think I have an idea of what's going on, and I expect that #3064 will provide at least some part of the fix. The CodeActionContext.Only field is not being propagated to gopls because of the outdated version of the language client, meaning that gopls has no way of knowing which code actions the user requested. If the file saved also has diagnostics associated with it, gopls will try to provide quick fixes, and those may take longer to compute, causing slow saves.

[stamblerre]

If anyone is willing to try debugging this a bit further, I just published https://github.com/stamblerre/vscode-go/releases/tag/v0.3, which is a version of the extension with all of the latest dependencies. Please give it a try and report here if "Running save participants..." is still an issue. You can install it with the following steps:

1. Download the Go-0.13.0.vsix file linked above.
2. Go to the extensions pane in VS Code. Select the Go extension and click "Disable".
3. Click the "..." in the top right corner of the pane.
4. Select "Install from VSIX..." and choose the Go-0.13.0.vsix file.

[pequalsnp]

I am having this issue pretty consistently.
OSX 10.15.3
VS Code 1.42.1

I'm attaching trace logs from a recent incident - hopefully that may help.
slowsave.log

[stamblerre]

@pequalsnp: Are you using gopls? The most helpful logs would be from gopls - they can be captured using the steps here.

[pequalsnp]

@stamblerre Yes, I am using gopls. I've got the trace logs from that, I'm attaching them.
slowsave-gopls.log

[stamblerre]

Thanks for sharing those logs! I think the main issue in your case is this error:

2020/02/26 14:07:42 initial workspace load failed: go [-e -json -compiled=true -test=true -export=false -deps=true -find=false -- ./... builtin]: exit status 1: go: code.uber.internal/communications/go-rosetta@v4.6.6+incompatible: unrecognized import path "code.uber.internal/communications/go-rosetta" (https fetch: Get https://code.uber.internal/communications/go-rosetta?go-get=1: dial tcp: lookup code.uber.internal: no such host)

gopls is unable to resolve the imports in your file and keeps trying to look them up. This is probably because you need to be connected to an internal network. I'll add a fix to surface these types of errors to the user.

[hyangah]

I forgot to mention that there is a new command: "File: Save Without Formatting", (alt+k, s) which bypasses formatting and code action.

[pcj]

I'm seeing this error as well in a go codebase using bazel, probably because gopls is having trouble loading imports. "go.useLanguageServer": false, is the unfortunate workaround at the moment for me.

[stamblerre]

@pcj: gopls doesn't really have good support for Bazel yet, so I'd suggest that as the correct fix (golang/go#37205).

[stamblerre]

Are people still having this issue? If so, can you please comment here and attach your gopls logs?

[vieirin]

Here the output log is

[2020-04-01 19:15:21.547] [exthost] [warning] ms-vscode.Go - Code actions of kind 'source.organizeImports 'requested but returned code action is of kind 'quickfix'. Code action will be dropped. Please check 'CodeActionContext.only' to only return requested code actions.

repeated x10

I took a while to get in this state again, is not a 'everytime' bug

[disksing]

It might be a coincidence, some background indexing might have finished, but just in case this helps somebody else, this is what I did and seems to work.

1 - Disable "use language server" in vscode GO extension
2 - Restart vscode
3 - Enable it again
4 - Restart vscode

It seems simply killall gopls can work too :-)

[hairyhenderson]

@stamblerre hi - I've been experiencing slowness for months, but today decided to actually look at the logs 😉

This seems to be happening in particular with private packages - I usually export GOPRIVATE=github.com/myorg on the CLI, but not sure how to set that in VSCode itself - maybe that's the root issue?

I've sanitized the entry, but basically I see this message over and over until it times out:

[Error - 4:30:04 PM] 2020/04/09 16:30:04 failed to load workspace packages, skipping diagnostics: go [-e -json -compiled=true -test=true -export=false -deps=true -find=false -modfile=/var/folders/fl/_fwkrjh50tvb2gpl2vr7snsdtd9vkb/T/go.myapp.553307453.mod -- github.com/myorg/myapp github.com/myorg/myapp/api ...a whole lot more package names... ]: exit status 1: go: github.com/myorg/my-private-pkg/v10@v10.3.0/go.mod: verifying module: github.com/myorg/my-private-pkg/v10@v10.3.0/go.mod: reading https://sum.golang.org/lookup/github.com/myorg/my-private-pkg/v10@v10.3.0: 410 Gone
	server response: not found: github.com/myorg/my-private-pkg/v10@v10.3.0: invalid version: unknown revision v10.3.0

	snapshot=305
	directory=file:///Users/hairyhenderson/go/src/github.com/myorg/myapp

LMK if that's helpful or if you need more information. This is with gopls version:

golang.org/x/tools/gopls 0.4.0
    golang.org/x/tools/gopls@v0.4.0 h1:G4+YP9kaV4dJb79J5MobyApxX493Qa6VoiTceUmxqik=

And VSCode:

Version: 1.44.0
Commit: 2aae1f26c72891c399f860409176fe435a154b13

[hyangah]

@hairyhenderson

 "go.toolsEnvVars": {
        "GOPRIVATE": "github.com/myorg"
    }

I think you will need to reload the vscode or restart gopls. You can check the gopls log to see what Go environment variable it is using (the info should be at the beginning of the gopls log.

[hairyhenderson]

oh! thanks @hyangah - yes that works. Is this documented somewhere?

[ungerik]

I am having this problem in 1.43 and 1.44 so working with Go is broken for months now, very frustrating.

Enabling/disabling gopls makes no difference. Either gopls gets stuck at 100% cpu utilization until some timeout or code running non gopls tools.

Setting go.toolsEnvVars GOPRIVATE to match my terminal environment also does not make any difference.

All go tools are at the latest version, but this never made any difference for this problem.

[ungerik]

Found it in the logs: the aleksandra.go-group-imports extension was the problem. Working fine after disable and restart.

[stamblerre]

Because there have been a number of issues filed about this bug, I've tried to consolidate the details in to #3179. I'm going to close this in favor of that issue.

[stamblerre]

Duplicate of #3179