Old image revision used in concurrent solve

The following scenario seems to use a stale image version even after resolving a new digest:

1. Push an image xyz to a registry
2. Start a solve that uses llb.Image("xyz") as the fs for llb.Run
3. While the solve from step 2 is still running, push a new version of xyz to the registry
4. While the solve from step 2 is still running, start a new solve that uses llb.Image("xyz") as the fs for llb.Run

Step 4 appears to use the stale image from step 1 even though the tag now resolves to a different digest.

Repro case: https://github.com/aaronlehmann/stale-repro

Output:

#1 docker-image://docker.io/library/alpine:latest
#1 resolve docker.io/library/alpine:latest
#1 resolve docker.io/library/alpine:latest 0.5s done
#1 CACHED

#2 mkdir /files && touch /files/6589414186244133292
#2 DONE 0.1s

#3 exporting to image
#3 exporting layers 0.0s done
#3 exporting manifest sha256:dd0d2b8362d2a44a09964381a7529f8fe44b990f24526342075e6fcba8553906 done
#3 exporting config sha256:704180e6c856456af321c49b25f7c83a22a7504195ec7ad69c10d94c7ee130d3 done
#3 pushing layers
#3 pushing layers 1.1s done
#3 pushing manifest for localhost:5000/alehmann/dummy:test@sha256:dd0d2b8362d2a44a09964381a7529f8fe44b990f24526342075e6fcba8553906
#3 pushing manifest for localhost:5000/alehmann/dummy:test@sha256:dd0d2b8362d2a44a09964381a7529f8fe44b990f24526342075e6fcba8553906 0.6s done
#3 DONE 1.7s
#1 docker-image://localhost:5000/alehmann/dummy:test
#1 resolve localhost:5000/alehmann/dummy:test
#1 resolve localhost:5000/alehmann/dummy:test 0.2s done
#1 DONE 0.2s

#2 find /files
#0 0.050 /files
#0 0.053 /files/6589414186244133292
#2 DONE 0.1s

#3 sleep infinity
#1 docker-image://docker.io/library/alpine:latest
#1 resolve docker.io/library/alpine:latest
#1 resolve docker.io/library/alpine:latest 0.5s done
#1 CACHED

#2 mkdir /files && touch /files/573052331943476811
#2 DONE 0.1s

#3 exporting to image
#3 exporting layers 0.0s done
#3 exporting manifest sha256:92beb7770d4a9774147f2e150333c24cec742895bd4992cd9c180e0fc9bbcc02 done
#3 exporting config sha256:72c672a7aecec165200f21bd9c710c7e79be131e176e29eff39543e05b92bea5 done
#3 pushing layers
#3 pushing layers 1.0s done
#3 pushing manifest for localhost:5000/alehmann/dummy:test@sha256:92beb7770d4a9774147f2e150333c24cec742895bd4992cd9c180e0fc9bbcc02
#3 pushing manifest for localhost:5000/alehmann/dummy:test@sha256:92beb7770d4a9774147f2e150333c24cec742895bd4992cd9c180e0fc9bbcc02 0.5s done
#3 DONE 1.6s
#1 docker-image://localhost:5000/alehmann/dummy:test
#1 resolve localhost:5000/alehmann/dummy:test 0.2s done
#1 DONE 0.2s

#2 find /files
#0 0.050 /files
#0 0.053 /files/6589414186244133292
#2 DONE 0.1s

#3 sleep infinity

It doesn't matter if the run command in step 4 is different from the one in step 2. But the concurrency does seem to matter: Changing the sleep infinity to sleep 1 (so the solves don't overlap) works around the problem.

Start with the linked stale-repro and reproduce the behavior with two overlapping solves. Trace concurrent image-tag resolution and cache behavior in BuildKit; the issue does not identify a source file or test. Done means the second solve uses the newly pushed digest even while the first solve is running.