There have been numerous reports of users seeing gopls freeze up, fail all request, and log "no room in queue". This seems to be a symptom of some larger gopls failure, likely a deadlock in the process of type-checking. It has been mentioned in discussions on https://github.com/golang/go/issues/32360 and https://github.com/golang/go/issues/31977.
This seems to happen because the defaultMessageBufferSize is set to 20 and RejectIfOverloaded is set to true for both client and server conns in jsonrpc2.
https://github.com/golang/tools/blob/master/internal/lsp/protocol/protocol.go#L14
https://github.com/golang/tools/blob/master/internal/jsonrpc2/jsonrpc2.go#L28
I think increasing the default to a more-reasonable 128, or just disabling RejectIfOverloaded should fix this issue.
After a bit of discussion, it seems reasonable to point out that this will not fix any request that happens to wedge the server, it would only fix a congestion issue that isn't a result of deadlock.
yes this issue exists for few days/weeks. gopls is being unable to use in windows or WSL
Chiming in with a bit of data... I'm now seeing this issue after the latest release
[Error - 11:23:07 AM] Request textDocument/documentLink failed.
Message: no room in queue
Code: -32000
[Error - 11:23:07 AM] Request textDocument/codeAction failed.
Message: no room in queue
Code: -32000
[Error - 11:23:07 AM] Request textDocument/documentSymbol failed.
Message: no room in queue
Code: -32000
[Error - 11:23:07 AM] Request textDocument/codeAction failed.
Message: no room in queue
Code: -32000
My build information
[Info - 10:55:10 AM] Build info
----------
version v0.0.1-20190607+alpha, built in $GOPATH mode
Go info
-------
go version go1.12.5 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/tonyghita/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/tonyghita/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12.5/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12.5/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/gv/vdmq3_l541b_0lq_ds37xslnzgdpkw/T/go-build209673958=/tmp/go-build -gno-record-gcc-switches -fno-common"
The "no room in queue" bug was crashing my gopls golangserver in VSCode every couple minutes since 2-3 weeks ago.
Finally, I lost my patience today and switched to "bingo". Hope this helps someone:
go get -u github.com/saibing/bingo
"go.useLanguageServer": true,
"go.alternateTools": {
"go-langserver": "bingo",
"gopls": "bingo"
},
"go.languageServerFlags": [
"--diagnostics-style=instant",
"--enhance-signature-help",
"--format-style=goimports",
"--goimports-prefix='github.com/pressly'", // enter your own here
],
"go.languageServerExperimentalFeatures": {
"autoComplete": true,
"documentSymbols": true,
"findReferences": true,
"format": true,
"goToDefinition": true,
"goToTypeDefinition": true,
"hover": true,
"signatureHelp": true,
"rename": true,
"workspaceSymbols": true,
},
@VojtechVitek: What version of gopls were you using (gopls version)? This bug is not entirely resolved, but those error messages should not have been appearing as of https://go-review.googlesource.com/c/tools/+/182458.
@stamblerre
$ gopls version
version v0.1.0-cmd.gopls, built in $GOPATH mode
Change https://golang.org/cl/183718 mentions this issue: internal/jsonrpc2: change the concurrency strategy
Most helpful comment
Chiming in with a bit of data... I'm now seeing this issue after the latest release
My build information