x/tools/gopls: client receives old diagnostics

[myitcv]

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

$ go version
go version devel +d2de9bd59c Thu Jan 16 04:02:37 2020 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20200116062425-473961ec044c
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.1.8-0.20200116062425-473961ec044c

Does this issue reproduce with the latest release?

Yes

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

go env Output

$ 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-build511293922=/tmp/go-build -gno-record-gcc-switches"

What did you do?

This may or may not be a problem; raising for completeness given previous CLs have sought to prevent old diagnostics being sent to the client.

Per conversations with @stamblerre we have a defence against this in place in govim so we are not seeing any problems in our tests. i.e. if these old diagnostics are ignored, the non-old diagnostics are as expected.

In a few tests we randomly see gopls sending govim old diagnostics. That is for a given file, we receive diagnostics for a version less than the latest version we received from gopls.

This doesn't appear to be specific to a given test/scenario.

Attached is a gopls log file from a test that looks to verify case insensitive completion:

gopls.log

The sequence of diagnostic notifications here is:

main.go v3
main.go v4
main.go v5
main.go v6
main.go v3
main.go v6
main.go v3
main.go v8
main.go v9

What did you expect to see?

Monotonically increasing version numbers for a file's diagnostics.

What did you see instead?

As above.

---

cc @stamblerre

FYI @leitzler

[myitcv]

@stamblerre I'll leave you to decide whether this is v0.3.0 or not. As I mention above we appear to be fine if we ignore these old diagnostics. But as I said, I'm raising for completeness' sake.

[stamblerre]

This does seem like a bug, particularly because it's this v3 that keeps coming back. I'm not sure if it's a v0.3.0 blocker, but it's definitely something to look into soon.

[myitcv]

Following a conversation with @leitzler yesterday, I think we need to consider this a v0.3.0 blocker.

I will try to explain why by making clear my understanding on a few points. Because if any of this is wrong my argument might well fall to pieces!

1. files that are not open in the editor have v == 0 in gopls
2. files that are open in the editor have v >= 1 and this version is controlled by the LSP client
3. open files that are subsequently closed are then have v == 0
4. gopls only sends diagnostics for a given file if those diagnostics have changed, regardless of whether the file is open in the editor or not (correct as of 872a348)
5. hence the client might end up in a situation where an open file is v4 but the current diagnostics for that file sent from gopls are v2 (because there were no changes to the diagnostics as a result of the changes in v3 and v4, or any other files for that matter)
6. diagnostics for a file can change without the version of that file changing, as a result of changes in other files
7. couple points 4, 5 and 6 with the async nature of diagnostics and the client cannot know whether, at any given point in time, it has the current diagnostics for any given file; it only knows that, under normal operation, the "right" diagnostics will eventually arrive
8. given point 6, the client cannot know how to order diagnostics for a file when the version number in the diagnostics does not change, regardless of whether the file is open or not
9. given point 8, the server has to guarantee that it will only ever send diagnostics for any given file according to the order defined by the time of the snapshot against which the diagnostics were calculated
10. correspondingly, the client has to blindly trust that the server is, at any given point in time, sending it "later" diagnostics for any given file
11. it's possible that the client will not receive diagnostics for all versions of a file

On Slack last night, I think @heschik reached the same conclusion as point 9:

I think maybe we should put back the recency check on diagnostics, but do it on snapshot ID instead of file version.

Given point 8 above (and the conclusion in point 9) I therefore think it is wrong/impossible for the client to try and drop non-new diagnostics. Hence, per @leitzler's observation, we should not be merging govim/govim#663.

It was suggested in #36452 (comment) that the client should only apply diagnostics for a file if that version matches the current (from the client's perspective) file version. Given points 4, 5 and 7 above, I think we have to conclude this is not possible. Rather that the client has to apply diagnostics on a "best efforts" basis, in the knowledge that, under normal operation, the "right" diagnostics will eventually arrive and "put things right".

My conclusions from the above are therefore:

• we have to make this issue a blocker for v0.3.0, and per @heschik implement a recency filter based on the time of snapshot against which diagnostics for a file were calculated
• we should not merge [DO NOT MERGE] cmd/govim: ignore non-new diagnostics govim/govim#663

Any corrections/comments etc on the above gratefully received 😄

[gopherbot]

Change https://golang.org/cl/215298 mentions this issue: internal/lsp: add recency check to avoid sending old diagnostics