-
Notifications
You must be signed in to change notification settings - Fork 18
Description
Our frontend emits synthetic vertices (initializing build, resolving image …) before BuildKit’s own graph starts.
When a synthetic vertex such as “initializing build” or “resolving image” is active, the progress header stops updating:
- The runtime display stays fixed at 0.0 s.
- The completed/total counter does not advance.
- The header begins updating again only after the first downstream BuildKit vertex appears.
Experiments performed
- Inserted a sleep in the synthetic phase so the vertex stays open for several seconds.
Result: header updates normally during the sleep, freezes again the instant the sleep ends.
⇒ Freezing is not caused merely by marking the vertex Completed “too early.”
Re-verified that subsequent SolveStatus.Statuses messages are still being sent after the freeze.
This eludes to the idea that the update path that drives the header is triggered by arrival of new vertices, not by status-only packets that reference an already-seen digest.
When the synthetic phase stops emitting new vertices (even though it continues to send status records) the header no longer receives a tick and stalls until the next real BuildKit vertex is created.
In short, the problem appears to live in the tracer/display logic that ties header refresh to vertex creation events, rather than in the timing of our Completed flag.