x/tools/gopls/internal/regtest/diagnostics: frequent timeouts on Windows starting 2022-06-08 #53371
Comments
gopherbot
added
Tools
bcmills
changed the title
|
Hrm, https://build.golang.org/log/1e581513fa4f6d26c7d333e4773e40781961c3d9 has a similar failurue mode but after a different test: |
bcmills
changed the title
bcmills
changed the title
|
This may be the same root cause as #53269. |
|
Change https://go.dev/cl/412394 mentions this issue: |
… and the module cache Since CL 410821 we were indexing these modules with a cache key based on the mtimes of the files within the module. However, that seems to be causing test failures (#53269 and maybe #53371). In addition, indexing these modules caused a potentially-expensive operation (re-indexing a whole module) whenever any individual file within the module is changed, even if it isn't relevant to the package(s) being loaded from that module. In some cases, that could cause a significant performance regression for 'go' commands invoked on a small subset of the packages in the module (such as running 'go test' on a single changed package — a common case during development). Instead, we now index only those modules found within the module cache and within GOROOT. In addition, we now check mtimes when indexing GOROOT modules if the Go version begins with the string "devel ", which indicates a non-released Go version that may include local file edits within GOROOT. For #53371. For #53269. Change-Id: Id3aa81b55ecfc478e47dd420148d39d2cf476f2d Reviewed-on: https://go-review.googlesource.com/c/go/+/412394 Reviewed-by: Michael Matloob <matloob@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com>
|
Lots of these in the run up to CL 412394 and none after. I'm calling this fixed.
|
greplogs -l -e '#### End Gopls Test Logs for "TestEditGoDirectiveWorkspace.*"\npanic: test timed out after 10m0s' --since=2022-01-012022-06-09T19:31:37-1d19788-2cfbef4/windows-arm64-10
2022-06-09T15:15:48-1d19788-840e99e/windows-386-2008
See previously #52040, #51930 (CC @hyangah, @findleyr, @suzmue),
The text was updated successfully, but these errors were encountered: