"Invalid channel id" error in go#lsp#DidChange (again?)

[robinbryce]

#2638 # What did you do? (required: The issue will be closed when not provided)

GOPATH project, (GO111MODULES not set)

Opened a go file. Opened a second file. Go the error in the picture below. Susequently the error pops up every few seconds making nvim unusable.

I think this may simply be a recurrence of #2467 for v0.5.0 of gopls ?

Reverting to gopls v0.4.1 resolved the issue

What did you expect to happen?

What happened instead?

Configuration (MUST fill this out):

vim-go version:

v1.24 (dev) commit 0a97926 (Mon Sep 21 13:46:22 2020 -0700

vimrc you used to reproduce:

Rather than provide a vimrc, I reverted to gopls v0.4.1 and confirmed the problem was resolved.

Vim version (first three lines from :version):

NVIM v0.4.4
Build type: Release
LuaJIT 2.0.5

Go version (go version):

go version go1.14.9 darwin/amd64

Go environment

go env Output:

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/puk/Library/Caches/go-build"
GOENV="/Users/puk/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/puk/jitsuin/quorum-rororo/build/_workspace"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go@1.14/1.14.9/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go@1.14/1.14.9/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
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/82/4dgwl1cs603d2h_l_nsj3jf80000gn/T/go-build843329381=/tmp/go-build -gno-record-gcc-switches -fno-common"

gopls version

gopls version Output:

v0.5.0

[bhcleek]

Are both the files you opened in the same module?

[robinbryce]

No, they were not. go-ethereum/params vs go-ethereum/cmd/geth I think

…

On Sun, 27 Sep 2020 at 17:25, Billie Cleek ***@***.***> wrote: Are both the files you opened in the same module? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3029 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6TXSMR2N3ODSYO6ZFSWWDSH5RO7ANCNFSM4R3QZZYA> .

[bhcleek]

Currently, you'll need to use :GoAddWorkspace to add the second module's root directory. However, can you try #3028 to see if it works for you without having to use :GoAddWorkspace?

I'm marking this as a duplicate and closing, because the behavior you're describing was already reported in #3026. Feel free to let me know if #3028 works for you either on that PR or in #3026.

[robinbryce]

Ah beg your pardon. Both files are in the same go module (go-ethereum). There is a symlink in play though due to how go-etherum (quorums fork) build system deals with GOPATH. Maybe the symlink causes gopls to *think* there are two modules ?

…

On Sun, 27 Sep 2020 at 21:42, Billie Cleek ***@***.***> wrote: Currently, you'll need to use :GoAddWorkspace to add the second module's root directory. However, can you try #3028 <#3028> to see if it works for you without having to use :GoAddWorkspace? I'm marking this as a duplicate and closing, because the behavior you're describing was already reported in #3026 <#3026>. Feel free to let me know if #3028 <#3028> works for you either on that PR or in #3026 <#3026>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3029 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6TXSNSCCNJGPLB6ILGF3TSH6PRXANCNFSM4R3QZZYA> .

[bhcleek]

I see. Symlinks generally will cause some problems with vim-go and Go generally for several reasons. What does your directory structure look like and where in that directory structure are the symlinks, especially as it relates to the files that you're opening?

If you're trying to do development with Go using a fork of some package in GOPATH mode, you can place your working tree of the fork at the expected location according to the desired import path. You may find using multiple remotes useful.