What causes "reading from image load response: %w" in GoogleContainerTools/skaffold?

Free disk space on the daemon host (`docker system prune`) — full disks commonly abort the unpack mid-stream.

reading from image load response: %w

Error message

reading from image load response: %w

What it means

In localDaemon.Load, after ImageLoad succeeds, the daemon's JSON response stream is consumed by streamDockerMessages. If that stream reports an error (e.g. the daemon rejected the archive mid-load, or the stream was interrupted), it is wrapped as "reading from image load response: %w". This is a failure during the load operation itself, after the request was accepted.

Source

Thrown at pkg/skaffold/docker/image.go:566

	})
	if err != nil {
		return fmt.Errorf("pulling image from repository: %w", err)
	}
	defer rc.Close()

	return streamDockerMessages(out, rc, nil)
}

// Load loads an image from a tar file. Returns the imageID for the loaded image.
func (l *localDaemon) Load(ctx context.Context, out io.Writer, input io.Reader, ref string) (string, error) {
	resp, err := l.apiClient.ImageLoad(ctx, input)
	if err != nil {
		return "", fmt.Errorf("loading image into docker daemon: %w", err)
	}
	defer resp.Close()

	if err := streamDockerMessages(out, resp, nil); err != nil {
		return "", fmt.Errorf("reading from image load response: %w", err)
	}

	return l.ImageID(ctx, ref)
}

// Tag adds a tag to an image.
func (l *localDaemon) Tag(ctx context.Context, image, ref string) error {
	_, err := l.apiClient.ImageTag(ctx, client.ImageTagOptions{Source: image, Target: ref})
	return err
}

// For k8s, we need a unique, immutable ID for the image.
// k8s doesn't recognize the imageID or any combination of the image name
// suffixed with the imageID, as a valid image name.
// So, the solution we chose is to create a tag, just for Skaffold, from
// the imageID, and use that in the manifests.
func (l *localDaemon) TagWithImageID(ctx context.Context, ref string, imageID string) (string, error) {
	parsed, err := ParseReference(ref)

View on GitHub (pinned to a1189de023)

Solutions

Free disk space on the daemon host (`docker system prune`) — full disks commonly abort the unpack mid-stream.
Validate the tar by loading it manually: `docker load -i <file>` to get the raw daemon error.
Regenerate the image archive — truncated or partially written tars fail mid-stream.
Retry after checking daemon logs (`journalctl -u docker` or Docker Desktop logs) for the underlying unpack error.

Defensive patterns

Strategy: try-catch

Validate before calling

// check daemon disk space before loading large images
du, err := client.DiskUsage(ctx)
if err == nil && freeDiskLow(du) { return errors.New("docker disk nearly full; prune first") }

Try / catch

id, err := daemon.Load(ctx, out, tar, ref)
if err != nil && strings.Contains(err.Error(), "reading from image load response") {
    log.Printf("load stream aborted; run `docker load -i <tar>` and `docker system prune`, then retry: %v", err)
}

Prevention

Run `docker system prune` periodically to avoid disk-full aborts mid-load.
Regenerate tars that were written by interrupted builds.
Avoid killing the process while Load is streaming.
Check daemon logs when loads repeatedly fail mid-stream.

When it happens

Trigger: Calling Load() where the response JSON stream from ImageLoad carries an error message: invalid layer data inside the tar, daemon ran out of disk space while unpacking, or the stream/connection was cut before completion.

Common situations: Docker disk full during image unpack, truncated tar stream (reader closed early), daemon restarted mid-load, incompatible image format inside an otherwise valid tar.

Related errors

AI-assisted analysis of GoogleContainerTools/skaffold@a1189de023 (2026-09-05). Data as JSON: /api/errors/58d07fe00bf616db. Report an issue: GitHub.