Previously, if this case occured, we would deadlock, so as to make this
case more easily identifiable and debuggable, we should panic instead.
Potentially, we could also just *skip* this case, but given that this is
an internal logical error that should not occur, it would be better to
identify this.
Signed-off-by: Justin Chadwell <me@jedevc.com>
When different LLB vertexes (eg. parallel requests referencing
local sources from different sessions) generate same cache keys
during solve they are merged together into a single operation.
Currently, when this happened the progress for the vertex that
was dropped got lost. This fixes this case by adding the
progressWriter of the redirected vertex as a target to the
source one.
This should also work with multiple levels of merged edges,
just multiple nested multiwriters as well.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
`MultiWriter` would create an unnecessary map allocation when the
`Write` method was used. The `Write` method would create a progress
object with the meta field initialized to the meta field of the writer
itself. It then invoked its own `WriteRawProgress` method which would
see two maps with the metadata and erroneously believe that they were
different and needed to be merged into a single metadata map.
Since this map is initialized with the metadata of the writer before
`WriteRawProgress` is invoked, this merge was unnecessary and could add
a lot of unnecessary memory allocations during a build.
This changes the `MultiWriter.Write` method to invoke the private
`writeRawProgress` which performs the actual write and avoids the
metadata merge.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
