Docker "failed to solve: rpc error: code = Canceled" in CI
By Kaveh Alemi·Latchkey
The build was cancelled mid-solve. rpc error: code = Canceled means the gRPC call to BuildKit was aborted - usually the job timed out, the runner/builder was torn down, or the buildkitd connection dropped while the build was running.
What this error means
A long-running build stops partway with failed to solve: rpc error: code = Canceled desc = context canceled. It is not a Dockerfile error - the build context was cancelled before it finished.
docker
#14 [build 5/7] RUN go build ./...
#14 CANCELED
ERROR: failed to solve: rpc error: code = Canceled desc = context canceled
Diagnose it: build context, cache, or platform?
A Dockerfile that builds locally and fails in CI usually differs in one of three ways: the build context contains different files, the layer cache is cold or poisoned, or the runner architecture does not match what the base image provides.
Terminal
# what is actually being sent as build context (dockerignore applies)
docker build --no-cache --progress=plain -t probe . 2>&1 | head -40
# what platform are you on, and what does the base image support?
docker version --format '{{.Server.Arch}}'
docker buildx imagetools inspect <base-image> | grep -i platform
# prove it is not a cache artefact
docker build --no-cache .
Common causes
The CI job hit its time limit
When the surrounding job is cancelled (timeout or manual cancel), buildx receives a cancellation and the in-flight solve is reported as Canceled.
The builder or runner was torn down mid-build
If the docker-container builder or the runner itself goes away during the build, the gRPC stream is cancelled.
buildkitd connection dropped
A dropped connection to buildkitd (crash, network blip) cancels the active solve.
How to fix it
Raise the job timeout and reduce build time
Give the build enough time and cut its duration with caching and parallelism.
Retry a build cancelled by infra, then stabilize the builder
A cancellation from a torn-down builder is retryable; a job-timeout cancellation needs a faster or longer-budgeted build.
Keep the build context small and deterministic
A missing .dockerignore sends node_modules, .git, and build output to the daemon, which is slow and can change layer hashes between environments.
A COPY of a path that exists locally but is gitignored will fail in CI, because the runner only has what the checkout produced.
Multi-arch builds need buildx and QEMU set up explicitly; a plain docker build on an ARM runner silently produces an ARM image.
How to prevent it
Set a job timeout that comfortably fits the build.
Cache layers so builds finish well inside the time budget.
Keep buildkitd healthy so connections do not drop mid-solve.
Frequently asked questions
What causes Docker "failed to solve: rpc error: code = Canceled" in CI?
There are 3 common causes: the ci job hit its time limit, the builder or runner was torn down mid-build, and buildkitd connection dropped. When the surrounding job is cancelled (timeout or manual cancel), buildx receives a cancellation and the in-flight solve is reported as Canceled.
How do I fix Docker "failed to solve: rpc error: code = Canceled" in CI?
There are 2 fixes depending on which cause you have: raise the job timeout and reduce build time and retry a build cancelled by infra, then stabilize the builder. Work through them in order, since the first is the most common.
What does Docker "failed to solve: rpc error: code = Canceled" in CI actually mean?
A long-running build stops partway with failed to solve: rpc error: code = Canceled desc = context canceled.
How do I stop Docker "failed to solve: rpc error: code = Canceled" in CI happening again?
Set a job timeout that comfortably fits the build. The prevention section lists 3 changes that keep it from recurring.
Can Latchkey fix this automatically?
Yes. Latchkey runs your GitHub Actions on managed runners that detect this failure, apply the fix, and retry the job automatically - self-healing is on by default.
