Intermittent "error writing layer blob: failed to reserve cache" during GHA cache export (gha exporter) — not quota, not permissions #6919

kavin238 · 2026-07-01T12:52:21Z

kavin238
Jul 1, 2026

Description

We're seeing intermittent, recurring failures during the GitHub Actions cache export step across multiple repositories, all using type=gha. The build and image push both complete successfully — the failure happens specifically during cache export, on what appears to be the very first blob write of the export.

This has been happening for a while now (previously worked reliably for months before failures started appearing), so it does not appear to be tied to a recent config change on our end.

Environment

docker/build-push-action@v6 (also reproduced on latest @v7)
docker/setup-buildx-action@v4
Buildx v0.35.0
BuildKit v0.30.0
GitHub-hosted ubuntu-latest runners
Docker Engine 28.0.4

Workflow (relevant excerpt)

```yaml

name: build-push
uses: docker/build-push-action@v6
with:
tags: /:
context: .
cache-from: type=gha
cache-to: type=gha,mode=max
push: true

```

Error log

```
#18 ERROR: error writing layer blob: failed to reserve cache

exporting to GitHub Actions Cache:

ERROR: failed to build: failed to solve: error writing layer blob: failed to reserve cache
Error: buildx failed with: ERROR: failed to build: failed to solve: error writing layer blob: failed to reserve cache
```

Notably, only one blob ever completes (writing layer sha256:... done) before the very next write fails — this pattern has been consistent across multiple separate failed runs, with different blob hashes each time. Image export and push (#17) complete without issue every time; only the cache export step (#18) fails.

What we've ruled out

Cache storage quota — repo usage sits at ~3.8GB of the 10GB limit at time of failure (confirmed via GET /repos/{owner}/{repo}/actions/cache/usage), so this isn't an eviction/capacity issue.
Token permissions — added actions: write to the job's permissions: block; no change in behavior.
Concurrent builds / scope collision — this repo never runs concurrent builds (single build per merge, no matrix, no parallel triggers), and only builds one image, so default scope=buildkit shouldn't be contended.
Retry-specific collision — reproduced on fresh, non-retried runs as well, not just re-runs of failed attempts.
Outdated tooling / legacy v1 cache API — Buildx/BuildKit versions are current; not seeing the known "This legacy service is shutting down..." error string associated with the v1 sunset.
Action version — reproduced on both docker/build-push-action@v6 and @v7.

Related issues

This looks structurally similar to:

travis: avoid cleaning up container #1409 — "Failing to push build cache should not fail the workflow" (same failure point — exporting to GitHub Actions Cache — different underlying error string, same overall category)
source: Have ResolveMode implement fmt.Stringer interface #577 — "Build should not fail on corrupted cache" (same "worked fine, started failing with no correlated change" pattern)

Answered by kavin238

Jul 13, 2026

Update: Got a response from GitHub Support — sharing the root cause and fix in case others hit this.
Root cause:
GitHub rolled out a change (June 26, 2026) that restricts cache write access for "low-trust" workflow triggers. Only these triggers can create/overwrite caches scoped to the default branch: push, workflow_dispatch, repository_dispatch, delete, registry_package, page_build, schedule. Any other trigger that resolves to the default branch gets read-only cache access — it can restore existing caches but can't write new ones.
Our CD workflow ran on pull_request with types: [closed]. That's normally fine, since pull_request runs are usually scoped to the temporary merge ref. But when…

View full answer

yudin-s · 2026-07-04T08:45:42Z

yudin-s
Jul 4, 2026

For this specific failure mode I would treat the gha cache export as best-effort, not as part of the correctness path.

Your image export and push already completed, and the failing step is only:

exporting to GitHub Actions Cache

The BuildKit docs list ignore-error=<false|true> as an --export-cache option, including for cache exporters. With docker/build-push-action, that maps directly into the cache-to CSV options:

- name: build-push
  uses: docker/build-push-action@v6
  with:
    tags: <ecr-registry>/<repo>:<tag>
    context: .
    cache-from: type=gha
    cache-to: type=gha,mode=max,ignore-error=true
    push: true

That will not make GitHub's cache reservation succeed, but it prevents an intermittent cache-service/export failure from failing a build whose actual image was already pushed successfully.

If you need the cache export itself to be reliable, I would switch this pipeline to a registry cache instead of type=gha, for example a dedicated ECR/GHCR cache ref:

cache-from: type=registry,ref=<ecr-registry>/<repo>:buildcache
cache-to: type=registry,ref=<ecr-registry>/<repo>:buildcache,mode=max

So my decision rule would be:

If the cache is only an optimization, use ignore-error=true.
If cache availability is required, use a registry-backed cache and keep gha out of the critical path.

If this solves the workflow failure mode, please mark the answer as accepted.

1 reply

kavin238 Jul 13, 2026
Author

Update: Got a response from GitHub Support — sharing the root cause and fix in case others hit this.
Root cause:
GitHub rolled out a change (June 26, 2026) that restricts cache write access for "low-trust" workflow triggers. Only these triggers can create/overwrite caches scoped to the default branch: push, workflow_dispatch, repository_dispatch, delete, registry_package, page_build, schedule. Any other trigger that resolves to the default branch gets read-only cache access — it can restore existing caches but can't write new ones.
Our CD workflow ran on pull_request with types: [closed]. That's normally fine, since pull_request runs are usually scoped to the temporary merge ref. But when the PR is actually merged (vs. just closed), GITHUB_REF switches to the fully-qualified ref of the branch it merged into — in our case, dev, our default branch. So the run got treated as running against the default branch, and since pull_request isn't on the trusted-trigger allowlist, it only had read access to the cache.

That's why Docker's buildx type=gha exporter failed with failed to reserve cache — "reserve" is a write call. The first new blob it tried to write got rejected; anything already cached could still be read (which is why one blob briefly succeeded before the failure).

Fix
Per GitHub Support's recommendation: swap the trigger from pull_request: closed to push on the target branch.

Answer selected by kavin238

Navigation Menu

Uh oh!

Intermittent "error writing layer blob: failed to reserve cache" during GHA cache export (gha exporter) — not quota, not permissions #6919

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

Intermittent "error writing layer blob: failed to reserve cache" during GHA cache export (gha exporter) — not quota, not permissions #6919

Uh oh!

kavin238 Jul 1, 2026

Description

Environment

Workflow (relevant excerpt)

Error log

``` #18 ERROR: error writing layer blob: failed to reserve cache

What we've ruled out

Related issues

Replies: 1 comment · 1 reply

Uh oh!

yudin-s Jul 4, 2026

Uh oh!

kavin238 Jul 13, 2026 Author

kavin238
Jul 1, 2026

```
#18 ERROR: error writing layer blob: failed to reserve cache

Replies: 1 comment 1 reply

yudin-s
Jul 4, 2026

kavin238 Jul 13, 2026
Author