Open bcmills opened 2 years ago
This appears to be more builder-specific than test-specific; maybe it's a bug in the test-runner infrastructure?
--- FAIL: TestClearAnalysisDiagnostics (35.55s)
--- FAIL: TestClearAnalysisDiagnostics/experimental (20.07s)
runner.go:316: waiting on:
Unmet: completed work "diagnosing initial workspace load" 1 times
err:context deadline exceeded
state:
#### log messages (see RPC logs for full text):
Info: "2022/01/18 18:08:15 go env for C:\\Users\\gopher\\...
#### diagnostics:
#### outstanding work:
diagnosing initial workspace load: 0.00
Setting up workspace: 0.00
Load: 0.00
#### completed work:
runner.go:312: closing editor: Shutdown: io: read/write on closed pipe
FAIL
FAIL golang.org/x/tools/gopls/internal/regtest/workspace 138.379s
greplogs --dashboard -md -l -e 'Unmet: completed work "diagnosing initial workspace load"' --since=2022-01-12
This means that gopls' initial workspace load is timing out on these builders:
Consider the following excerpt from the logs:
[Trace - 18:08:14.808 PM] Received notification '$/progress'.
Params: {"token":"6426100070888298971","value":{"kind":"begin","title":"Load","message":"Loading query=[builtin mod.com/...]"}}
...
[Trace - 18:08:32.828 PM] Received notification '$/progress'.
Params: {"token":"7981306761429961588","value":{"kind":"end","message":"Finished loading packages."}}
I think a reasonable next step is to add additional instrumentation around loading: how long did go list
take vs other phases in loading.
Change https://golang.org/cl/380497 mentions this issue: internal/lsp/regtest: eliminate arbitrary timeouts
greplogs --dashboard -md -l -e 'FAIL: TestFilters'
2022-01-12T19:47:40-d7a4bb4-f005df8/windows-arm64-10
And then there are a whole lot of
openbsd-386
failures on the builders affected by #49209, which IMO we can safely ignore:CC @findleyr