Cache restore fails with "File exists" errors when setup-go is called twice in the same job

[philip-gai]

When actions/setup-go@v6 is called twice in the same job, the second invocation's cache restore fails because all the Go module files already exist on disk from the first restore.

Go module cache files under ~/go/pkg/mod are read-only by design (go get removes write permissions), so when the second tar extraction attempts to overwrite them, it fails with thousands of Cannot open: File exists errors and ultimately:

##[warning]Failed to restore: "/usr/bin/tar" failed with error: The process '/usr/bin/tar' failed with exit code 2

Action version

actions/setup-go@v6

Platform

• Ubuntu
• macOS (untested)
• Windows (untested)

Runner type

• Hosted
• Self-hosted

Tools version

Go 1.24.5 (read from go.mod)

Repro steps

Any job that calls setup-go twice with caching enabled will trigger this.

Minimal example:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-go@v6
        with:
          go-version-file: go.mod
          # cache: true (default)

      # Any second call to setup-go with cache enabled triggers the issue
      - uses: actions/setup-go@v6
        with:
          go-version-file: go.mod

This is especially easy to hit when using composite actions or reusable workflows that internally call setup-go, since the caller may not be aware of the duplicate invocation.

First setup-go call:

• Installs Go, restores ~508MB module cache successfully
• Extracts to ~/go/pkg/mod and ~/.cache/go-build

Second setup-go call:

• Finds Go already in tool cache, resolves the same cache key
• Downloads and attempts to extract the same ~508MB archive
• tar fails on every file: Cannot open: File exists
• Emits ##[warning]Failed to restore

Expected behavior

When setup-go is called multiple times in the same job with the same cache key, the second invocation should gracefully handle the case where cached files already exist on disk. Possible approaches:

1. Skip restore if already done — detect that the cache was already restored in this job (e.g., via an environment variable or state) and skip the second restore entirely
2. Use tar --skip-old-files — avoid errors when files already exist during extraction
3. Handle tar exit code 2 as non-fatal — when the only errors are "File exists", treat the restore as successful

Actual behavior

The second cache restore downloads the full archive, attempts extraction, fails with thousands of ##[error] lines for every file, and emits a ##[warning]Failed to restore message. While the job typically succeeds (since the files are already present), this produces noisy logs and unnecessary network traffic.

Related issues

• setup-go action should allow for existing cache files #403 — Similar tar errors but focused on self-hosted runners; closed due to inactivity
• Tar errors on cache restore after toolchain installation #424 — Tar errors from toolchain installation; reportedly fixed in v6 via Improve toolchain handling #460, but does not cover the multiple-invocation scenario

[priya-kinthali]

Hello @philip-gai👋,
Thank you for reporting this issue. We will investigate it and get back to you as soon as we have some feedback.

[maxcleme]

Got hit by the same issue, I'm using an action that relies on setup-go behind the scene but then I also need to use setup-go. I can't make caching working for both of them.

[lmvysakh]

Hi @maxcleme,


We wanted to let you know that we have begun investigating this issue. We are actively looking into the matter and exploring the most effective approach to resolve it. We will keep you updated on this thread as soon as we have more findings or a proposed fix to share.


We appreciate your patience in the meantime, and please don't hesitate to add any further observations that might assist our investigation.