What version of Go are you using (go version)?

$ go version
go version devel +73d213708e Sat Jan 25 16:34:18 2020 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20200124220429-8fe064f891f2
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.1.8-0.20200124220429-8fe064f891f2

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/gostuff/src/github.com/myitcv/govim/go.mod"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build912581415=/tmp/go-build -gno-record-gcc-switches"

What did you do?

We have a govim test that verifies the setting of the "env" value GOFLAG=-mod=readonly. It is based on the following setup:

-- go.mod --
module mod.com

go 1.13
-- main.go --
package main

import "example.com/blah"

func main() {
	println(blah.Name)
}

(example.com/blah is a valid module and is accessible).

We initially verify that we have the following diagnostic:

PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
    URI:         "file:///tmp/go-test-script844433945/script-config_set_env_goflags_mod_readonly/main.go",
    Version:     1,
    Diagnostics: {
        {
            Range: protocol.Range{
                Start: protocol.Position{Line:2, Character:7},
                End:   protocol.Position{Line:2, Character:25},
            },
            Severity:           1,
            Code:               nil,
            Source:             "compiler",
            Message:            "could not import example.com/blah (no package for import example.com/blah)",
            Tags:               nil,
            RelatedInformation: nil,
        },
    },If applicable, copy/paste the text or add screenshots to help explain your problem.

}

However we often (~50% of the time, which is actually 100% of the time on CI, I can't reproduce locally) do not receive this diagnostic.

The following errors are logged by gopls:

Params: {"type":1,"message":"2020/01/26 21:52:32 diagnose: no workspace packages: go [-e -json -compiled=true -test=true -export=false -deps=true -find=false -- ./... builtin]: exit status 1: build mod.com: cannot load example.com/blah: import lookup disabled by -mod=readonly\n\n\tdirectory = 0xa932b0"}

What's interesting is that when this test passes we do not see this or any errors logged by gopls.

Given I can't repro this locally it suggests there's an element of timing involved.

What did you expect to see?

Consistently receiving an initial diagnostic from gopls for main.go

What did you see instead?

As above.

• gopls log for failing test: fail.log
• gopls log for passing test: pass.log

Marking as v1.0.0 because this isn't critical for v0.3.0 to my mind.

cc @stamblerre

FYI @leitzler