Progress bar's tag id keeps being too small

[yifu]

(Already poste on discord in the #Help channel, since no one answered I'm trying here)

Context:

I am trying to write an open source application which helps in downloading files from one machine to another on the same network/LAN.

You may find the current code source here: https://github.com/yifu/pushpop.

Problem:

The progress bar, for the download, never gets updated, or when it does then it is quite erratic. I would say it's always below the real total of downloaded bytes.

When I debug this application, with delve, then I observe that the tag inside the progress.FrameMsg is (nearly) always below the (expected) tag inside the progress model. Since there is a line in the ProgressBar Update() function which checks if the msg's tag has the correct value, then a nil command is returned afterwards:

progress.go (line 209-215)

// If you're rendering with ViewAs you won't need this.
func (m Model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
    switch msg := msg.(type) {
    case FrameMsg:
        if msg.id != m.id || msg.tag != m.tag {
            return m, nil
        }

As a consequence the progress bar never gets updated (quasi never), since the resulting command is nil (nearly always).

Questions:

What I am doing wrong here? It looks like the messages are somehow "buffered" before being sent to the main application thread, thus the progress model tag is incremented too much before the first message has the opportunity to be processed. Is there some "buffering" issues?

Or ... Can it be a bug? May a fix could be the following?

// If you're rendering with ViewAs you won't need this.
func (m Model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
    switch msg := msg.(type) {
    case FrameMsg:
        if msg.id != m.id || (msg.tag <= m.lastProcessedTag && msg.tag > m.lastGeneratedTag)  {
            return m, nil
        }

[MukundaKatta]

Your diagnosis is exactly right — you're hitting the progress.Model's tag-versioning guard. It's not a bug, it's the mechanism that prevents stale FrameMsgs from glitching the animation when multiple SetPercent calls arrive in quick succession. The tag check discards messages older than the latest target, which is what happens when you drive progress updates faster than the frame-tick rate.

Why this happens with a file-copy loop

Every SetPercent(x) bumps the internal tag and schedules a tween. If you call SetPercent again before the previous tween emits its first FrameMsg, the tag bumps a second time — and when the tween's frame finally arrives, it's stamped with the old tag and gets discarded. In a network download where Copy-style loops dispatch SetPercent at 1000+ Hz, practically every FrameMsg is stale.

Two fixes, pick one

Option A: use progress.Model.ViewAs(percent) — no tweening, no tags

If you don't specifically need the smooth animated fill, this is one line:

// In your View() method, don't store percent on the progress model.
// Just compute it and pass in:
return m.progress.ViewAs(m.downloadedBytes / float64(m.totalBytes))

ViewAs is a synchronous render — no internal state, no FrameMsg tagging. Every render reflects the current value exactly. This is what the Bubble Tea team recommend for non-interactive progress (the comment above Update() in progress.go, line 208, says exactly this).

For a network-download progress bar, ViewAs is almost always what you want. The tweening is for UI affordances like "user clicked install" where the snap from 0% to 100% feels abrupt; for actual byte-level progress, snapping is correct.

Option B: throttle SetPercent calls to the frame rate

If you want to keep the tweened animation, rate-limit your SetPercent dispatches so the tween has time to complete:

// In your download goroutine:
var lastUpdate time.Time

for {
    n, err := reader.Read(buf)
    // ...
    downloaded += int64(n)

    if time.Since(lastUpdate) > 33*time.Millisecond { // ~30 Hz
        program.Send(progressMsg{percent: float64(downloaded) / float64(total)})
        lastUpdate = time.Now()
    }
}

Then in your Update, turn progressMsg into m.progress.SetPercent(msg.percent). 30 Hz is comfortably above the tween cadence, so tags stay in sync.

Diagnostic I'd run

To confirm it's really the tag race and not something else, add a print right before the dropped FrameMsg:

case progress.FrameMsg:
    // quick diagnostic
    fmt.Fprintf(os.Stderr, "FrameMsg id=%d tag=%d (model id=%d tag=%d)\n",
        msg.id, msg.tag, m.progress.ID(), m.progress.Tag())
    newProgress, cmd := m.progress.Update(msg)

You'll see the tags drifting. Once you apply either fix, they stay aligned.

Why ViewAs is almost always the right choice here

Progress bars in Bubble Tea come in two shapes: (1) "animated fill" (the tween) for short, punctuated updates like an install step, and (2) "live readout" for long-running I/O like a file download. The tween exists to smooth (1); driving it with a download loop fights it. For (2), ViewAs + emitting a progressMsg at display cadence (not byte-receipt cadence) is the pattern that holds up.

Either fix gets you unstuck, but I'd reach for ViewAs for a file-transfer tool.