Skip to content

Debugger does not pause when copying a non-existent file #3437

Description

@rcjsuen

Contributing guidelines

I've found a bug and checked that ...

  • ... the documentation does not mention anything about my problem
  • ... there are no open or closed issues that are related to my problem

Description

When trying to debug a Dockerfile build that uses COPY on something that does not exist in the build context, the debug session is terminated instead of pausing. In comparison, if I do RUN cat non-existent-file.txt the debugger does pause so I would have expected the COPY call to also suspend the debug session instead of simply terminating.

Expected behaviour

The debug session should suspend instead of terminating.

Actual behaviour

The debug session terminates.

Buildx version

github.com/docker/buildx v0.29.0-rc1-2-gb4b698c0 b4b698c

Docker info

Client:
 Version:    28.4.0
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.9.11
    Path:     /Users/rcjsuen/.docker/cli-plugins/docker-ai
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.29.0-rc1-2-gb4b698c0
    Path:     /Users/rcjsuen/.docker/cli-plugins/docker-buildx
  cloud: Docker Cloud (Docker Inc.)
    Version:  v0.4.27
    Path:     /Users/rcjsuen/.docker/cli-plugins/docker-cloud
  compose: Docker Compose (Docker Inc.)
    Version:  v2.39.4-desktop.1
    Path:     /Users/rcjsuen/.docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.42
    Path:     /Users/rcjsuen/.docker/cli-plugins/docker-debug
  desktop: Docker Desktop commands (Docker Inc.)
    Version:  v0.2.0
    Path:     /Users/rcjsuen/.docker/cli-plugins/docker-desktop
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.31
    Path:     /Users/rcjsuen/.docker/cli-plugins/docker-extension
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     /Users/rcjsuen/.docker/cli-plugins/docker-init
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  v0.20.0
    Path:     /Users/rcjsuen/.docker/cli-plugins/docker-mcp
  model: Docker Model Runner (Docker Inc.)
    Version:  v0.1.40
    Path:     /Users/rcjsuen/.docker/cli-plugins/docker-model
  offload: Docker Offload (Docker Inc.)
    Version:  v0.4.27
    Path:     /Users/rcjsuen/.docker/cli-plugins/docker-offload
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /Users/rcjsuen/.docker/cli-plugins/docker-sbom
  scout: Docker Scout (Docker Inc.)
    Version:  v1.18.3
    Path:     /Users/rcjsuen/.docker/cli-plugins/docker-scout

Server:
 Containers: 2
  Running: 0
  Paused: 0
  Stopped: 2
 Images: 39
 Server Version: 28.4.0
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Discovered Devices:
  cdi: docker.com/gpu=webgpu
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 05044ec0a9a75232cad458027ca83437aae3f4da
 runc version: v1.2.5-0-g59923ef
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.10.14-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 14
 Total Memory: 7.653GiB
 Name: docker-desktop
 ID: bdffc6bd-ef47-45bc-9cbc-9e2bd56bc69d
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=unix:///Users/rcjsuen/Library/Containers/com.docker.docker/Data/docker-cli.sock
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false

Builders list

NAME/NODE           DRIVER/ENDPOINT     STATUS    BUILDKIT   PLATFORMS
default             docker
 \_ default          \_ default         running   v0.24.0    linux/amd64 (+2), linux/arm64, linux/ppc64le, linux/s390x, (2 more)
desktop-linux*      docker
 \_ desktop-linux    \_ desktop-linux   running   v0.24.0    linux/amd64 (+2), linux/arm64, linux/ppc64le, linux/s390x, (2 more)

Configuration

FROM node:24-alpine AS stage
COPY non-existent-file.txt .

Debug this file with VS Code and it just terminates instead of suspending.

Build logs


Additional info

No response

Activity

  1. jsternberg commented on Oct 6, 2025

    @jsternberg
    Collaborator

    Need to check if this gets resolved by #3450 or can be resolved as part of it.

    I suspect the reason for this is because of the failure mode. When we stop on failure, we rely on the code path for exec which only supports stopping on exec calls. It might be considering the failure to be a non-builder failure and just exiting. I'll check it out.

  2. added theissue type on Oct 6, 2025
  3. self-assigned this
    on Oct 6, 2025
  4. added this to the v0.30.0 milestone on Oct 6, 2025
  5. jsternberg commented on Oct 15, 2025

    @jsternberg
    Collaborator

    Diving into this quite a bit. The problem seems to be with the rewind function. What rewind tries to do is find the actual digest that failed by taking the op that was returned as part of the solve error, remarshaling it to find the digest, and finding that in the build graph.

    It seems like we're seeing a different digest for this one. I did a hexdump of the two and it seems like the solve error returns a JSON blob that includes the platform but the original solve that we did returns a representation that doesn't include the platform.

    Now I just need to figure out if it's a bug that we didn't get back the platform from the solve or if we need to filter the platform from the solve error to determine what's the correct way to go about this.

    Basically: The solve error we use to find the error step that failed is returning more information than it expects. Not sure where the correct place to inject or remove that extra information needs to go. I suspect the data is supposed to be there though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions