This is a follow up issue for golang/vscode-go#2406. That issue reports a rare but severe breakage that made it into the firstname.lastname@example.org release. Several processes broke down to let that happen, so this issue tracks improvements we can make to help avoid such regressions in the future.
Background: Gopls runs go vet analyzers for open packages. When new analyzers are added to vet (in the x/tools/go/analysis directory), they can be included in gopls via inclusion in internal/lsp/source.defaultAnalyzers. In this case, a new analyzer was added that accidentally included a print statement. Any print to stdout corrupts gopls' jsonrpc2 communication with the LSP client.
Action items (these are subject to change, as we go through our postmortem):
Release email@example.com containing the fix
Include an automated configuration diff in the gopls release process. This would have highlighted the new analyzer.
Add a meta test that sanity checks that all gopls analyzers are exercised by at least one test.
Consider redirecting os.Stdout in gopls, perhaps to os.Stderr.
Investigate whether we can improve the vscode-go error message when the jsonrpc2 stream gets corrupted.
The text was updated successfully, but these errors were encountered:
This release fixes an unfortunate bug in a new vet analysis in the
firstname.lastname@example.org release. Specifically, a stray print statement in a
new analyzer for the invalid time format string "2006-02-01", which
corrupts gopls' communication over STDIN/STDOUT.
This only affects projects using that bad format string, and only
when a file in the affected package is open. Thanks to @Phadin for
accurately identifying this bug so quickly after it was introduced.
Issue golang/go#54459 tracks our follow-up to prevent similar
regressions from making it into future gopls releases.
On a positive note, here is the new vet analysis in action. Clearly
it will catch real bugs!