The error comes from x/tools/internal/lsp/fake/sandbox.go:
https://cs.opensource.google/go/x/tools/+/master:internal/lsp/fake/sandbox.go;l=270;drc=384460091cd7916680a7c5252c587572c601197e

However, it appears that the directory for which the error occurs always refers to TestPostfixSnippetCompletion. I suspect a synchronization error in that test: perhaps some process or goroutine started by the test is continuing to write to the directory while the Sandbox is attempting to remove it.

This is a release-blocker via #11811; it is causing frequent failures in the builders, especially for darwin/amd64 and darwin/arm64 (which are first-class ports).

(If the root cause isn't readily apparent, I suggest that we skip TestPostfixSnippetCompletion to reduce test-failure noise until someone has time to investigate.)

Change https://golang.org/cl/379735 mentions this issue: gopls/internal/regtest/completion: temporarily skip TestPostfixSnippetCompletion

Thanks. I'll look into this with urgency.

I'd really llke to understand this failure mode, as this test is not doing a lot of IO: it doesn't even use any on-disk Go files, just a go.mod. All Go state exists only in in-memory buffers.

Looking at it briefly, I noticed that the test is repeatedly "opening" the same buffer, which I would expect to panic but doesn't (we should change that). However, I wouldn't expect that to cause this failure.

Disabling cleanup leaves the sandbox in the following state. None of this state should change following initial workspace load.

> find .
.
./work
./work/go.mod
./gopath
./gopath/pkg
./gopath/pkg/mod
./gopath/pkg/mod/cache
./gopath/pkg/mod/cache/lock
./proxy

CC @adonovan

Looked into this today, and it revealed a memory leak in gopls. When we create a processEnv for running goimports, we acquire the snapshot: https://cs.opensource.google/go/x/tools/+/master:internal/lsp/cache/imports.go;l=146;drc=53ead67a981c04bcacdd4f593330c43ee9285578

But the process env is associated with the view, and so this snapshot is never released.

As a result, we hold on to whichever snapshot was used to create the process env. As time passes the data referenced by this snapshot becomes staler and staler, and is increasingly duplicated. In very brief testing this leak seemed significant.

Change https://go.dev/cl/416594 mentions this issue: internal/lsp: wait for snapshot shutdown before shutting down the server