x/tools/gopls: stale diagnostic, possibly from an orphaned workspace package #43347
Labels
FrozenDueToAge
gopls/metadata
Issues related to metadata loading in gopls
gopls
Issues related to the Go language server, gopls.
Testing
An issue that has been verified to require only test changes, not just a test failure.
Tools
This label describes issues relating to any tools in the x/tools repository.
Projects
Milestone
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 thePackagesForFile
) 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 nearbypackages.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
The text was updated successfully, but these errors were encountered: