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

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

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)