buildkitd panic around dep.req.Request().(*edgeRequest).desiredState

[imeoer]

panic: interface conversion: interface {} is nil, not *solver.edgeRequest

goroutine 28 [running]:
github.com/moby/buildkit/solver.(*edge).createInputRequests(0xc051a11680, 0x1, 0x1, 0x0)
        /go/src/github.com/moby/buildkit/solver/edge.go:812 +0xbd4
github.com/moby/buildkit/solver.(*edge).unpark(0xc051a11680, {0xc05e9f5200, 0x1, 0x1}, {0xc05e9f5210, 0xc059c2fe50, 0x1}, {0xc031c312f0, 0x3, 0x3}, ...)
        /go/src/github.com/moby/buildkit/solver/edge.go:362 +0x1dd
github.com/moby/buildkit/solver.(*scheduler).dispatch(0xc000024850, 0xc051a11680)
        /go/src/github.com/moby/buildkit/solver/scheduler.go:136 +0x2e5
github.com/moby/buildkit/solver.(*scheduler).loop(0xc000024850)
        /go/src/github.com/moby/buildkit/solver/scheduler.go:104 +0x1da
created by github.com/moby/buildkit/solver.newScheduler
        /go/src/github.com/moby/buildkit/solver/scheduler.go:35 +0x207

Version: v0.10.3

Very small probability of occurrence, currently not sure about the reproduction steps yet.

[alekitto]

Same error, doesn't always fail, it seems that occur randomly.
Currently using buildx bake to build 4 images concurrently and push them to GCP registry, using cache-from in all four images, but no cache-to.

panic: interface conversion: interface {} is nil, not *solver.edgeRequest

goroutine 23 [running]:
github.com/moby/buildkit/solver.(*edge).createInputRequests(0xc002016780, 0x3, 0x4?, 0x0)
        /src/solver/edge.go:814 +0xb14
github.com/moby/buildkit/solver.(*edge).unpark(0xc002016780, {0xc000ecf640, 0x4, 0x4}, {0xc0006dddb0?, 0x0, 0x0}, {0xc003844670, 0x1, 0x1}, ...)
        /src/solver/edge.go:363 +0x1da
github.com/moby/buildkit/solver.(*scheduler).dispatch(0xc00019cbd0, 0xc002016780)
        /src/solver/scheduler.go:136 +0x2e5
github.com/moby/buildkit/solver.(*scheduler).loop(0xc00019cbd0)
        /src/solver/scheduler.go:104 +0x1e8
created by github.com/moby/buildkit/solver.newScheduler
        /src/solver/scheduler.go:35 +0x218

Version: v0.11.3

[alexcb]

This is still occurring in master (40c5efa); however there's no easy replication case for it.

[coryb]

closing this issue, it should be resolved by #3953