Download failed after {} retries due to stream interruption

Error message

Download failed after {} retries due to stream interruption

What it means

resp.chunk() failed mid-body (connection reset, premature EOF, or the 120s read timeout) and the stream-interruption retry counter reached MAX_RETRIES = 10. Each retry resumed from disk via a Range header, so bytes already written to the .partial file are preserved unless the failure path deletes them; the message reports only the exhausted retry count.

Source

Thrown at crates/goose-download-manager/src/lib.rs:638

                                progress.eta_seconds = eta_seconds;
                            }
                        }
                    }
                    Ok(None) => break,
                    Err(e) => {
                        info!(model_id = %model_id, bytes = *cumulative_bytes, error = %e, "Download stream interrupted, will retry");
                        stream_error = true;
                        break;
                    }
                }
            }

            file.flush().await?;
            drop(file);

            if stream_error {
                if retries >= Self::MAX_RETRIES {
                    anyhow::bail!(
                        "Download failed after {} retries due to stream interruption",
                        retries
                    );
                }
                retries += 1;
                let delay = std::cmp::min(
                    Self::RETRY_BASE_DELAY * 2u32.saturating_pow(retries - 1),
                    Self::RETRY_MAX_DELAY,
                );
                info!(model_id = %model_id, retry = retries, delay_secs = ?delay.as_secs(), "Retrying download with resume");
                Self::cancellable_sleep(delay, downloads, model_id).await?;
                continue;
            }

            break;
        }

        tokio::fs::rename(&partial_path, destination).await?;

View on GitHub (pinned to 3810898a74)

Solutions

Stabilize the network (wired link, different VPN endpoint) and restart the download: it resumes from the .partial file
If you control the deployment, raise the client read timeout (120s) or reduce per-file size by choosing a smaller quantization
Persist the failure and let the user retry later instead of auto-looping immediately into the same environment

Defensive patterns

Strategy: retry

Try / catch

if err.to_string().contains("due to stream interruption") {
    // ten mid-body breaks in a row: stabilize the link, then call download again -
    // the .partial file is reused and the Range header resumes from disk
}

Prevention

Prefer stable links (wired/known-good VPN) for multi-GB GGUF transfers
Restart from the same model_id so completed shards and partial bytes are reused
Do not auto-retry in a tight loop after this error; the environment, not the code, must change

When it happens

Trigger: Ten consecutive mid-body stream breaks on one file: flaky Wi-Fi/mobile links, VPN or proxy terminating long responses, NAT idle timeouts, or HF CDN connections reset repeatedly during multi-GB transfers.

Common situations: Laptops on unstable networks downloading sharded models; corporate proxies with aggressive response timeouts; satellite/high-latency links where 120s read stalls recur.

Related errors

AI-assisted analysis of aaif-goose/goose@3810898a74 (2026-08-16). Data as JSON: /api/errors/72962d76e1d4ad4e. Report an issue: GitHub.