Module pull_progress 

Multi-bar progress for decdn bundle pull.

A bundle pull run fetches many blobs concurrently, so it renders a stack of per-file bars — one per pull that holds a --jobs slot, plus any that wait for a sibling’s donor chunks — above one bottom total bar, all sharing an indicatif::MultiProgress, under a one-line header naming the run and its download vs on-disk sizes. A finished file’s bar clears, so only active pulls stay on screen.

The total bar meters the run’s download — the bytes actually fetched after shared-chunk dedup (download_bytes), fixed up front as its denominator so it reads “downloaded of the whole download” from the start. Only delivered bytes fold into it (each file’s delivery callback, capped at that file’s download size); bytes spliced from disk are free and never inflate it, so its rate and ETA describe real transfer, not reconstruction. The header shows the download total beside the whole on-disk content size (total_content_bytes), so the dedup saving is visible.

A per-file bar reads downloaded/download-total (reconstructed) plus a phase word. During the download it tracks the pull’s delivered content against the blob’s download size; when the download is done but a deferred chunk is still being fetched by a sibling it shows pending siblings…; during the whole-file verify it shows reconstructing… and fills with bytes hashed, so a multi-GB reconstruction never sits as a frozen row; before the first byte it shows discovering…. A per-file bar carries no rate/ETA: with --jobs pulls sharing one link, a single file’s rate is only its share of the bandwidth and reads as stuck whenever another file has the bandwidth, while the total bar keeps moving.

The total bar and header are shown only when the manifest declares sizes. A blob with no declared size contributes nothing to the denominator. If no kept entry (one that survives the include/exclude filters) declares a size, the total bar is omitted and only per-file bars render.

In a terminal that supports the OSC 9;4 progress sequence (iTerm2, Ghostty, WezTerm, Windows Terminal, and others; detected by anstyle-progress, as Cargo does), the total bar’s percent also drives the terminal’s own progress indicator in the tab bar or dock. A run with no total bar shows it as indeterminate. The indicator is removed when the run finishes or the renderer drops.

The whole renderer is silent — every bar a no-op, every file’s delivery callback None — when stderr is not a terminal or the run is --json, so piped and scripted output carries no progress-bar bytes.