microsoft/vscode-go

Go To Symbol breaks after a few uses

heschi opened this issue · 3 comments

heschi commented

What version of Go, VS Code & VS Code Go extension are you using?

  • Run go version to get version of Go
    • go version go1.14 linux/amd64
  • Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders
    • 1.44.0
  • Check your installed extensions to get the version of the VS Code Go extension
    • 1.14.1
  • Run go env GOOS GOARCH to get the operating system and processor architecture details
    • linux amd64

Share the Go related settings you have added/edited

    "go.useLanguageServer": true,
    "go.languageServerFlags": [
        "-rpc.trace", // for more detailed debug logging
        "serve",
        "--debug=localhost:6060", // to investigate memory usage, see profiles
    ],   
    "go.lintOnSave": "off", 
    "[go]": {
        // "editor.snippetSuggestions": "none",
        "editor.formatOnSave": true,
        "editor.codeActionsOnSave": {
            "source.organizeImports": true,
        }
    },
    "gopls": {
        "usePlaceholders": true, // add parameter placeholders when completing a function
        "matcher": "fuzzy",
        // Experimental settings
        "staticcheck": false,
        "verboseOutput": true,
    },

Describe the bug

Go To Symbol stops working after some number of uses with no obvious root cause. It just hangs, with a neverending progress spinner below the search bar.

Steps to reproduce the behavior:

Press ctrl-T to open the search bar. Type a bunch of letters in quickly. Press escape to close the search box, then repeat a few times. For me it always breaks within ~30 seconds of playing with it. When it's broken, it no longer sends workspace/symbol requests to gopls, so I think the problem must be on the VS Code side, perhaps some bug in cancellation handling.

Screenshots or recordings

I can learn how to take a recording if necessary.

hyangah commented

I originally thought this was an upstream vscode or vscode lsp client issue, but I failed to repro with a simple extension with a workspace symbol provider, or with a simple language server. Looking into all gopls traces we captured, I noticed a pattern like the following:

[Trace - 16:10:43.847 PM] Sending request 'workspace/symbol - (42)'.
Params: {"query":"unimp"}

[Trace - 16:10:43.863 PM] Sending notification '$/cancelRequest'.
Params: {"id":42}

[Error - Received] 16:10:43.864 PM #42 context canceled

The workspace/symbol request cancelled later never returned. According to the LSP spec, LSP clients will still expect a response.

A request that got canceled still needs to return from the server and send a response back. It can not be left open / hanging. This is in line with the JSON RPC protocol that requires that every request sends a response back. In addition it allows for returning partial results on cancel. If the request returns an error response on cancellation it is advised to set the error code to ErrorCodes.RequestCancelled.

Based on prior discussion such as microsoft/vscode#58560 (comment) I am guessing VSCode will not invoke the workspace symbol provider again until the previous invocation is resolved. Maybe not returning the response cause the lsp-based workspace symbol provider to hang.

@stamblerre @heschik Can you please check if gopls correctly sent the response for the cancelled request in this case?

hyangah commented

Submitted the CL and I hope it to be picked up in one of the next gopls releases.
cc/ @stamblerre