8000 Saving is very slow because waiting for "Quick Fixes" [flaky] · Issue #3063 · microsoft/vscode-go · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
This repository was archived by the owner on Jul 15, 2023. It is now read-only.

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

Closed
broady opened this issue Feb 24, 2020 · 25 comments
Closed

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

broady opened this issue Feb 24, 2020 · 25 comments
Labels
needs more info

Comments

@broady
Copy link
Contributor
broady commented Feb 24, 2020

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 broady changed the title Can't save because waiting for "Quick Fixes" [flaky] Saving is very slow because waiting for "Quick Fixes" [flaky] Feb 24, 2020
@broady
Copy link
Contributor Author
broady commented Feb 24, 2020

Looks like it does complete eventually (~20 seconds)

@hyangah
Copy link
Contributor
hyangah commented Feb 24, 2020

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
  • Outp 8000 ut > Log (Extension Host)

@broady
Copy link
Contributor Author
broady commented Feb 24, 2020

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

@wkalt
Copy link
Contributor
wkalt commented Feb 24, 2020 •
edited
Loading

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
Copy link
migmartri commented Feb 25, 2020 •
edited
Loading

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
Copy link
migmartri commented Feb 25, 2020 •
edited
Loading

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

Selection_999(394)

@stamblerre
Copy link
Contributor

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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

@pequalsnp
Copy link

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

@stamblerre
Copy link
Contributor

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

gopherbot pushed a commit to golang/tools that referenced this issue Feb 26, 2020
@stamblerre
internal/lsp: mitigate possiibility of a slow code action
204d844 
Related to microsoft/vscode-go#3063.
A small collection of fixes: (1) Don't reload packages with missing
dependencies unless imports change. (2) Show the error message from the
initial workspace load to the user.

Also, a small fix for deletion suggested fixes - upgrading to the latest
version of the VS Code language client revealed that I had made a
mistake there.

Change-Id: I7ab944ed27dc3da24a79d5d311531a1eb2b73102
Reviewed-on: https://go-review.googlesource.com/c/tools/+/221217
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
@hyangah
Copy link
Contributor
hyangah commented Feb 28, 2020

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

@AbelHu AbelHu mentioned this issue Mar 2, 2020
Closed
@pcj
Copy link
pcj commented Mar 4, 2020

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
Copy link
Contributor

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

@hyangah hyangah mentioned this issue Mar 16, 2020
Closed
@stamblerre
Copy link
Contributor

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

@vieirin
Copy link
vieirin commented Apr 2, 2020 •
edited
Loading

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

@stamblerre stamblerre mentioned this issue Apr 2, 2020
Closed
@disksing
Copy link
disksing commented Apr 9, 2020

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

Selection_999(394)

It seems simply killall gopls can work too :-)

@hairyhenderson
Copy link

@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
Copy link
Contributor
hyangah commented Apr 9, 2020

@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
Copy link

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

@ungerik
Copy link
ungerik commented Apr 10, 2020

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
Copy link
ungerik commented Apr 10, 2020

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

@stamblerre stamblerre mentioned this issue Apr 15, 2020
Closed
@stamblerre
Copy link
Contributor

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
Copy link
Contributor

Duplicate of #3179

@stamblerre stamblerre marked this as a duplicate of #3179 Apr 15, 2020
@stamblerre stamblerre reopened this Apr 15, 2020
@vscodebot vscodebot bot locked and limited conversation to collaborators May 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
needs more info
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
0