Docker context is not registered properly under load

Contributing guidelines

• I've read the contributing guidelines and wholeheartedly agree

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

Cross-posting from https://github.com/moby/moby/issues/50160

When I run the testcase normally the context name is interpreted properly and the operation completes successfully, but when I run the same sequence of steps under load the context name is interpreted as a hostname and the operation fails. I am expecting the operation to pass under load.

Specifically, the context name shouldn't be evaluated as a hostname given that I am explicitly marking it using --context. What's super annoying is that this issue is only reproducible under load.

Can you please take a peek at the code and check if context create is guaranteed to block until the context is fully created, initialized and registered everywhere it needs to be? There must be some sort of race condition there.

Sometimes I see buildx inspect pass (implying that the context and builder were both found) but then buildx build fails immediately thereafter with the same error (implying that the context isn't registerd at the same time for buildx inspect as it is for buildx build). This is very odd, but consistently showing up every couple of runs.

Expected behaviour

The command should succeed

Actual behaviour

The command fails

Buildx version

github.com/docker/buildx v0.25.0 faaea65da4ba0e58a13cd9cadcb950c51cf3b3c9

Docker info

Client:
 Version:    28.2.2
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.4.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-ai.exe
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.25.0
    Path:     C:\Users\Gili\.docker\cli-plugins\docker-buildx.exe
  cloud: Docker Cloud (Docker Inc.)
    Version:  v0.3.9
    Path:     C:\Program Files\Docker\cli-plugins\docker-cloud.exe
  compose: Docker Compose (Docker Inc.)
    Version:  v2.37.1-desktop.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-compose.exe
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.41
    Path:     C:\Program Files\Docker\cli-plugins\docker-debug.exe
  desktop: Docker Desktop commands (Docker Inc.)
    Version:  v0.1.9
    Path:     C:\Program Files\Docker\cli-plugins\docker-desktop.exe
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.29
    Path:     C:\Program Files\Docker\cli-plugins\docker-extension.exe
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-init.exe
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  dev
    Path:     C:\Program Files\Docker\cli-plugins\docker-mcp.exe
  model: Docker Model Runner (Docker Inc.)
    Version:  v0.1.24
    Path:     C:\Program Files\Docker\cli-plugins\docker-model.exe
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sbom.exe
  scout: Docker Scout (Docker Inc.)
    Version:  v1.18.1
    Path:     C:\Users\Gili\.docker\cli-plugins\docker-scout.exe

Server:
 Containers: 1
  Running: 1
  Paused: 0
  Stopped: 0
 Images: 257
 Server Version: 28.2.2
 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 nvidia 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.6.87.1-microsoft-standard-WSL2
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 31.31GiB
 Name: docker-desktop
 ID: 1b4701e4-7636-48b9-a06d-2e79bae42e32
 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=npipe://\\.\pipe\docker_cli
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: DOCKER_INSECURE_NO_IPTABLES_RAW is set

Builders list

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

Configuration

1. Run docker.exe context create --docker host=tcp://localhost:33997,ca=certs\ca\cert.pem,cert=certs\client\cert.pem,key=certs\client\key.pem SwarmIT.demoteLastManager.manager where the target container is running docker:dind.
2. stdout returns:

SwarmIT.demoteLastManager.manager`

3. stderr returns:

Successfully created context "SwarmIT.demoteLastManager.manager"

4. The command returns exitcode 0.
5. Then run docker --context SwarmIT.demoteLastManager.manager buildx inspect
6. stdout returns:

Name:   SwarmIT.demoteLastManager.manager
Driver: 
Error:  unable to parse docker host `SwarmIT.demoteLastManager.manager`

Build logs

Additional info

No response

Start by reproducing the sequence using docker context create, then docker --context ... buildx inspect and buildx build under load. Trace how context creation is registered before the inspect and build entry points use it; done means the named context is never parsed as a hostname and both operations succeed reliably under load.