x/tools/gopls: "internal error reading (shared cache|typerefs data)" bug report (via telemetry)

[adonovan]

This stack -iVK7w was reported by telemetry:

	// Access the cache.
	var summary *analyzeSummary
	const cacheKind = "analysis"
	if data, err := filecache.Get(cacheKind, key); err == nil {
		// cache hit
		analyzeSummaryCodec.Decode(data, &summary)
		if summary == nil { // debugging #66732
			bug.Reportf("analyzeSummaryCodec.Decode yielded nil *analyzeSummary")
		}
	} else if err != filecache.ErrNotFound {
		return nil, bug.Errorf("internal error reading shared cache: %v", err) // <--- here
	} else {

gopls/bug
golang.org/x/tools/gopls/internal/util/bug.report:+35
golang.org/x/tools/gopls/internal/util/bug.Errorf:+2
golang.org/x/tools/gopls/internal/cache.(*analysisNode).runCached:+24
golang.org/x/tools/gopls/internal/cache.(*Snapshot).Analyze.func6.1:+4
golang.org/x/sync/errgroup.(*Group).Go.func1:+3
runtime.goexit:+0

golang.org/x/tools/[email protected] go1.20.4 windows/amd64 vscode (1)

Issue created by golang.org/x/tools/gopls/internal/telemetry/cmd/stacks.

Dups: m4MTKQ

[adonovan]

The possible causes of this failure are:

• can't create cache (e.g. disk full?)
• can't hash executable (e.g. gopls unlinked, or chmodded?)
• I/O error reading index file (e.g. EACCES, EISDIR, ENOENT?)

The first seems the most likely. The others can only happen if someone is meddling with the executable or the cache directory.

[adonovan]

Very different stack, but same cause. (Probably the same user given the rarity, timing, and OS/ARCH.)

func (s *Snapshot) typerefData(ctx context.Context, id PackageID, imports map[ImportPath]*metadata.Package, cgfs []file.Handle) ([]byte, error) {
	key := typerefsKey(id, imports, cgfs)
	if data, err := filecache.Get(typerefsKind, key); err == nil {
		return data, nil
	} else if err != filecache.ErrNotFound {
		bug.Reportf("internal error reading typerefs data: %v", err) // <-- here
	}

This stack m4MTKQ was reported by telemetry:

gopls/bug
golang.org/x/tools/gopls/internal/util/bug.report:+35
golang.org/x/tools/gopls/internal/util/bug.Reportf:+1
golang.org/x/tools/gopls/internal/cache.(*Snapshot).typerefData:+5
golang.org/x/tools/gopls/internal/cache.(*Snapshot).typerefs:+8
golang.org/x/tools/gopls/internal/cache.(*packageHandleBuilder).buildPackageHandle:+19
golang.org/x/tools/gopls/internal/cache.(*Snapshot).getPackageHandles.func2.1:+8
golang.org/x/sync/errgroup.(*Group).Go.func1:+3
runtime.goexit:+0

golang.org/x/tools/[email protected] go1.20.4 windows/amd64 vscode (1)

Issue created by golang.org/x/tools/gopls/internal/telemetry/cmd/stacks.

[findleyr]

Looked at this briefly. We should probably not have a bug that can be reasonably triggered by an OS error, but should also do a better job of surfacing this error to the user. Bumping to v0.18.

[adonovan]

Looked at this briefly. We should probably not have a bug that can be reasonably triggered by an OS error, but should also do a better job of surfacing this error to the user. Bumping to v0.18.

I think all we need to do here is treat ENOSPC as a cache miss. As a bonus we might also want to showMessage an error when the space in the cache volume is tight; currently we report just an internal event when filecache.Set fails.