#!stacks
("bug.Reportf" || "bug.Errorf") && 
  ("runCached:21" || "runCached:+24" || "runCached:+18" || /* analysis */
   "typerefData:+5" ||  /* typerefs */
   "cache.(*Snapshot).Symbols.func1:+15") /* symbols */

Note that similar errors have been observed in three different places that call filecache.Get, as indicated by the comments in the pattern above. Presumably the underlying cause is the same in all cases.

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/gopls@v0.15.3 go1.20.4 windows/amd64 vscode (1)

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

Dups: m4MTKQ UFNCpw e960MA T1ADGg HYjhzQ S3fsGA n0XcvA pM2JYg m1H29g 9gpe3A

Comment From: 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.

Comment From: 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/gopls@v0.15.3 go1.20.4 windows/amd64 vscode (1)

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

Comment From: 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.

Comment From: 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.

Comment From: adonovan

This stack UFNCpw was reported by telemetry:

golang.org/x/tools/gopls@v0.14.2 go1.21.4 darwin/arm64 other (6)

Comment From: adonovan

This stack e960MA was reported by telemetry:

golang.org/x/tools/gopls@v0.14.2 go1.21.4 darwin/arm64 other (6)

Comment From: adonovan

This stack e960MA was reported by telemetry:

golang.org/x/tools/gopls@v0.14.2 go1.21.4 darwin/arm64 other (6)

Comment From: adonovan

This stack T1ADGg was reported by telemetry:

golang.org/x/tools/gopls@v0.17.1 go1.23.4 darwin/arm64 other,vscode (3)

Comment From: gopherbot

Change https://go.dev/cl/639395 mentions this issue: gopls/internal/filecache: Get: mitigate failure due to ENOSPC

Comment From: adonovan

This stack HYjhzQ was reported by telemetry:

golang.org/x/tools/gopls@v0.17.1 go1.23.4 darwin/arm64 other,vscode (3)

Comment From: adonovan

Hasn't been observed since the Jan 3 mitigation was released. Presuming fixed.

Comment From: adonovan

This stack S3fsGA was reported by telemetry:

golang.org/x/tools/gopls@v0.19.0-pre.2 go1.24.2 linux/amd64 other,vscode (1)

Comment From: adonovan

This stack n0XcvA was reported by telemetry:

golang.org/x/tools/gopls@v0.19.1 go1.24.4 darwin/arm64 other,vscode (4)

This stack pM2JYg was reported by telemetry:

golang.org/x/tools/gopls@v0.19.1 go1.24.4 darwin/arm64 other,vscode (5)

Comment From: adonovan

Hmm, 9 reports with the same config string, likely from a single user. That rules out both "disk full" and "failed to create cache" causes since both were mitigated by logic added to gopls/main.go. And it seems unlikely that the disk repeatedly filled up, or the cache as deleted, while gopls was running, 9 times. Very strange.

Comment From: adonovan

This stack m1H29g was reported by telemetry:

golang.org/x/tools/gopls@v0.19.1 go1.24.4 linux/amd64 other (1)

Comment From: adonovan

This stack 9gpe3A was reported by telemetry:

golang.org/x/tools/gopls@v0.20.0 go1.24.4 linux/amd64 other,vscode (1)