x/tools/gopls: stale diagnostic, possibly from an orphaned workspace package #43347
Description
I encountered a strange and concerning bug in gopls yesterday (using gopls/v0.6.1), which presented as follows:
While working on the regtests, I typed e.Sandbox.RunGoCommand (a function), at which point I got a go/types diagnostic for the unused ExprStmt. I then kept typing, but the "is unused" diagnostic stuck around. Subsequently editing and saving the file did not eliminate or move the diagnostic -- it was republished for each snapshot. My first thought is that this is a bug in diagnostic caching, but I don't yet see how that could be possible and the following evidence suggests otherwise: I have a diagnostic delay configured and the initial publish after editing (which only diagnoses the PackagesForFile) cleared the erroneous diagnosic, then it came back on the subsequent delayed diagnostics pass, which diagnoses all workspace packages.
We (@stamblerre and I) therefore suspected that I somehow had an orphaned workspace package which is no longer associated with the file I was editing. If this were possible we would not invalidate this typechecked package upon edits to the file, its stale diagnostics would persist across snapshots, and it would not be part of the PackagesForFile package set and therefore wouldn't be present in the initial diagnostics pass. In other words, the symptoms would be exactly what I observed. On the other hand I don't yet see how a package could be orphaned in such a way, and nothing I did while editing the file would have triggered abnormal code paths (in my RPC logs there are no nearby packages.Load calls that would have affected package associations).
So after staring at this for a bit, I'm currently at a loss. While the bug persisted in my gopls session, I unfortunately did not have the debug server enabled and was unsurprisingly not able to reproduce in a new session. Eventually, after an ~hour in the broken session, the stale diagnostic just went away.
This is likely a rare enough bug that it is relatively low impact, but its nature demonstrates that some invariant of the gopls server is being broken. I therefore think we should proceed by instrumenting gopls to assert loudly on the invariants we expect: logging errors in production builds and crashing in development builds.
CC @stamblerre @heschik @pjweinbgo