Submit an issue View all issues Source
MIR-1136

Deploy upload progress total estimate swings wildly during slow uploads

Done public
phinze phinze Opened May 13, 2026 Updated May 14, 2026

The Uploading artifacts: X% — N KB / ~M MB at S/s line in m deploy shows a "total" that drifts all over the place as the upload proceeds. Observed on a slow upload (2.4 KB/s, 45 files): initial estimate ~974 KB, climbed steadily to ~80 MB, with periodic drops back down to ~20 MB. After ~7 minutes the line still read 1%.

The math lives in enrichUploadProgress in cli/commands/deploy.go:932:

p.Fraction = float64(written.Load()) / float64(totalUncompressed)
if p.Fraction > 0 {
    p.EstimatedTotalBytes = int64(float64(p.BytesRead) / p.Fraction)
}

The two counters are sampled at different points in the pipeline:

  • written is uncompressed bytes that have entered the tar/gzip stage.
  • BytesRead is compressed bytes drained by the HTTP uploader on the other side of a gzip buffer + io.Pipe.

Under network back-pressure the two advance in bursts at very different ratios, so EstimatedTotal = BytesRead / Fraction produces a moving estimate rather than a stable one. The displayed % (also derived from Fraction) is "fraction of source bytes pulled into gzip," not "fraction of upload complete."

Proposed fix: drop the synthetic total. We know totalUncompressed up front, so display progress as written / totalUncompressed for the percentage, and show BytesRead + BytesPerSecond alongside without inventing a compressed total we don't actually know. Smaller change, more honest, and the line stops dancing.

(Separately worth investigating: slow upload throughput. Already being tracked elsewhere.)