Using multiple build commands at the same time ignores cache locks

Description of bug

Running docker buildx bake commands in separate terminals at the same time races locked caches on the same builder. Additionally max-parallelism in the buildkitd config is ignored.

✅ When one docker buildx bake command is run with two targets that share a stage with a locked cache mount, the behavior is as expected, with one target blocking the other.

❌ When two docker buildx bake commands are run simultaneously with one target each, and as above share an intermediate stage with a locked cache, the lock is ignored and the observed caching behavior is similar to private.

✅ when two docker buildx bake commands are run specifically such that the second starts immediately after the first leaves the locked stage, the second enjoys the cached result.

This is a bug because there is no reason to distinguish between two commands with one target or two targets with one command using the same builder instance. If the cost of building twice is desired, two builders can be used, or a private cache can be specified rather than a locked one. This is a bug.

Version information

github.com/docker/buildx v0.23.0 28c90ea

[jason@tuwumono01 tuwunel]$ docker builder inspect --builder jevolk
Name:          jevolk
Driver:        docker-container
Last Activity: 2025-06-05 10:05:40 +0000 UTC

Nodes:
Name:                  jevolk0
Endpoint:              unix:///var/run/docker.sock
Status:                running
BuildKit daemon flags: --allow-insecure-entitlement network.host
BuildKit version:      v0.21.1
Platforms:             linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/386
Labels:
 org.mobyproject.buildkit.worker.executor:         oci
 org.mobyproject.buildkit.worker.hostname:         90797ec1624a
 org.mobyproject.buildkit.worker.network:          host
 org.mobyproject.buildkit.worker.oci.process-mode: sandbox
 org.mobyproject.buildkit.worker.selinux.enabled:  false
 org.mobyproject.buildkit.worker.snapshotter:      overlayfs
GC Policy rule#0:
 All:            true
 Filters:        label!=cache==pin
 Reserved Space: 256GiB
 Max Used Space: 576GiB
File#buildkitd.toml:
 > 
 > [system]
 >   platformsCacheMaxAge = "504h"
 > 
 > [worker]
 > 
 >   [worker.oci]
 >     enabled = true
 >     gc = true
 >     maxUsedSpace = "576GB"
 >     reservedSpace = "256GB"
 >     rootless = false
 > 
 >     [[worker.oci.gcpolicy]]
 >       all = true
 >       filters = ["label!=cache==pin"]
 >       maxUsedSpace = "576GB"
 >       reservedSpace = "256GB"
 >

Start by reproducing the race with two simultaneous docker buildx bake commands targeting a shared locked cache, then compare it with two targets in one command. Read the cache-lock handling and max-parallelism behavior in the BuildKit daemon, using the provided buildkitd configuration as context. Done means concurrent commands honor the shared lock and configured parallelism.