x/tools/internal/lsp: TryBot failure in upgradedep

[jayconrod]

When testing CL 237017, I saw TryBot failures on two tests:

• TestLSP/Modules/testdata/upgradedep/CodeLens/go.mod
• TestLSP/Modules/testdata/upgradedep/Link/go.mod

I couldn't reproduce this locally (darwin, amd64) or in a VM (linux, amd64). I was able to reproduce it through gomote on linux-amd64. The failure doesn't happen every time; I had to use -count=5 or so.

The failing command is:

go list -modfile=/workdir/tmp/go.lsp.218695923.mod -mod readonly -u -m all

The .mod file is the same as the one in testdata. There's no .sum file in testdata, so I'm not really sure how that gets populated when this test passes.

I'd actually expect the command above to fail when go.sum is absent or incomplete. It should write sums for .mod files loaded during MVS. It should fail because of -mod readonly.

Given that this happens irregularly, I suspect the go list -u -m command above is racing with whatever sets up the test workspace and populates the go.sum file.

cc @stamblerre @ianthehat

[heschi]

There are somewhat similar flakes on the builders across multiple tests: https://build.golang.org/log/e954e51ef512c8b2149f6233c26f33ca3fa31294
https://build.golang.org/log/471447bf31a433d96ae5b53e4e015c9c8c1f8b3f

[stamblerre]

Thanks - I didn't realize these tests were already flaky. Converting to regtests sounds like the right path to me - I'll try to do that today.

[heschi]

They're not -- those are completely unrelated tests failing with what looks like a similar root cause to me.

[stamblerre]

Oh thanks for clarifying, should've checked the logs. Maybe it is because our testdata has a go.mod but not go.sum. Still, the initial workspace load should handle setting up the temporary go.sum and that should definitely run before any of these tests start.

[pjweinb]

Me too: modest changes in unrelated code, and ran trybots 3 times, and each time 1/10 failed in TestCommandLine, each time a different trybot.

[pjweinb]

here's references to the logs:
Failed on windows-386-2008: https://storage.googleapis.com/go-build-log/e92be18f/windows-386-2008_d2cf68fe.log
Failed on linux-amd64 (Go 1.14.x): https://storage.googleapis.com/go-build-log/83b181c6/linux-amd64_7bcc844b.log
Failed on openbsd-amd64-64: https://storage.googleapis.com/go-build-log/e92be18f/openbsd-amd64-64_121cdfa3.log

[gopherbot]

Change https://golang.org/cl/237419 mentions this issue: internal/lsp: await the initial workspace load in ModHandle

[stamblerre]

We're fairly certain that this is caused by our reuse of the same temporary go.mod file for every go command call. I'll put up a follow-up CL that switches to use one temporary go.mod file per invocation.

[gopherbot]

Change https://golang.org/cl/237517 mentions this issue: internal/lsp: use a new temporary go.mod for every go list call