Fix Docker BuildKit Canceled Errors in CI

DEV Community

Docker failed to solve: rpc error: code = Canceled in CI

Docker failed to solve: rpc error: code = Canceled is not a fault report. It is BuildKit relaying that the call carrying your build was canceled, in wording that comes from gRPC and from the Go standard library rather than from Docker, and the only useful question is which program did the canceling. The words "rpc error: code = Canceled desc =" are formatted by gRPC and "context canceled" by the Go standard library. Only "failed to solve" belongs to Docker tooling. What this error means A build that was making progress stops partway. One step shows as CANCELED rather than as an error, and the job ends with a solve failure carrying a gRPC code and the words context canceled. No step reported a problem of its own, and rerunning the same commit frequently succeeds. The block below is assembled from the strings each program formats, not captured from a job. ```Reconstructed from the formatting in buildx, the BuildKit client, gRPC and Go context 14 [build 5/7] RUN go build ./... 14 CANCELED ERROR: failed to solve: rpc error: code = Canceled desc = context canceled

Common causes

The job hit its timeout

The simplest cause and the easiest to confirm, because the job duration will sit right on the configured limit. Note that a job with no timeout-minutes still has a platform limit, so an unset timeout is not the same as no timeout. A build that grew past its budget produces this line every time rather than intermittently.

A concurrency group canceled the run

With cancel in progress set, a new push cancels the previous run for the same group, and every job in it stops wherever it was. This presents as intermittent failures that correlate with how often people push, which is a pattern worth recognizing because it looks like flakiness and is not. The run page says the run was canceled.

The builder or the runner went away underneath the build

A builder container killed for memory, a runner reclaimed, or a self hosted machine restarting all take down the far end. Whether you get a cancellation or a status failure depends on the order in which things tear down, which is why this cause appears on two pages. If the run page shows failure rather than cancellation, this is the branch you are on.

buildx canceled its own solve after the stream went quiet

The client cancels a solve that is already failing once its status stream has been inactive for a few seconds, so the command exits rather than hanging. That converts a different underlying problem into a Canceled line. Treat a cancellation with no timeout and no cancel in progress rule as a pointer to look for what was going wrong before it.

How to fix it

Look at the run page before you look at the build

1. If the run is marked canceled, the cause is outside the build and the build log has nothing more to give you.
2. Compare the job duration to timeout-minutes. Equal means the timeout, not the build.
3. If the run is marked failed and nothing canceled it, treat the line as a symptom and look at the last step that made progress.

Scope the concurrency group so unrelated work does not cancel your builds

A group keyed only on the workflow cancels across branches and across unrelated pull requests. Keying it on the ref as well means a push cancels only its own previous run, which is almost always what people meant.

```.github/workflows/build.yml
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
Make the build finish comfortably inside its budget Raising the timeout is the fix only when the build is genuinely that long. Otherwise the cheaper move is to stop redoing work: a registry or GitHub Actions cache on the build turns a cold build into a warm one and usually moves the duration far enough from the limit that the cause stops mattering. - uses: docker/build-push-action@v7
with:
context: .
cache-from: type=gha
cache-to: type=gha,mode=max
Keep the step that tells you where it stopped Plain...

Powered by Readybot.io