Zackriya-Solutions/meetily · error

Progress overflow while resuming {}

Error message

Progress overflow while resuming {}

What it means

When resuming a partially downloaded artifact, the server returns 206 and the engine credits the already-downloaded range_start bytes to the progress accumulator via checked_add. Overflow here is practically impossible for real file sizes, so this error indicates corrupted size accounting — e.g. range_start derived from a bogus local file size or corrupted artifact totals.

Source

Thrown at frontend/src-tauri/src/parakeet_engine/parakeet_engine.rs:925

                last_percent = progress.percent;
                last_report = Instant::now();
                continue;
            }

            let file_url = format!("{}/{}", base_url.trim_end_matches('/'), artifact.filename);
            let range_start = (local_bytes > 0 && local_bytes < artifact.exact_bytes)
                .then_some(local_bytes);
            let response = self
                .send_download_request(&client, &file_url, range_start, active_download)
                .await?;

            let (response, mut artifact_bytes, append) = match range_start {
                Some(range_start) => match response.status() {
                    reqwest::StatusCode::PARTIAL_CONTENT => {
                        Self::validate_partial_response(&response, range_start, artifact.exact_bytes)?;
                        confirmed_bytes = confirmed_bytes
                            .checked_add(range_start)
                            .ok_or_else(|| anyhow!("Progress overflow while resuming {}", artifact.filename))?;
                        let progress =
                            Self::in_flight_progress(confirmed_bytes, total_bytes, 0.0);
                        if let Some(callback) = &progress_callback {
                            callback(progress.clone());
                        }
                        self.set_downloading_status(model_name, progress.percent).await;
                        last_percent = progress.percent;
                        last_report = Instant::now();
                        (response, range_start, true)
                    }
                    reqwest::StatusCode::OK => {
                        Self::validate_full_response(&response, artifact.exact_bytes)?;
                        (response, 0, false)
                    }
                    reqwest::StatusCode::RANGE_NOT_SATISFIABLE => {
                        Self::validate_unsatisfied_response(&response, artifact.exact_bytes)?;
                        let retry = self
                            .send_download_request(&client, &file_url, None, active_download)

View on GitHub (pinned to a2cb62e827)

Solutions

1. Delete the partial artifact file so the download restarts from zero (no resume path taken).
2. Verify the partial file's real size (ls -l / stat) and remove files with implausible lengths.
3. Reset the model cache directory entirely and re-download.
4. If reproducible with normal files, file a bug — checked_add is a safety net and should never fire.

Example fix

// before: bloated/holey partial file triggers overflow-sized resume
-rw-r--r-- 1 user staff 18446744073709551615 model.int8.onnx  (corrupted)
// after: remove and restart
rm "~/Library/Application Support/Meetily/models/parakeet/model.int8.onnx"

// verify partial file sizes are plausible before resuming
let md = tokio::fs::metadata(&partial_path).await?;
assert!(md.len() <= artifact.exact_bytes,
    "partial {} larger than artifact ({} > {}) — delete it",
    partial_path.display(), md.len(), artifact.exact_bytes);

match download_result {
    Err(e) if e.to_string().contains("Progress overflow while resuming") => {
        // corrupted partial/state: restart the artifact from zero
        delete_partial(model_dir, filename).await?;
        retry_download().await
    }
    other => other,
}

When it happens

Trigger: checked_add(confirmed_bytes, range_start) overflows u64 during resume — only reachable if the local partial file's metadata().len() or confirmed_bytes is corrupt/astronomically large (near u64::MAX).

Common situations: A corrupted or maliciously enlarged partial file on disk (length near u64::MAX, e.g. sparse/holey file left by a crashed writer); corrupted progress state across artifacts; inconsistent total_bytes vs per-artifact sizes from a bad manifest.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• Progress overflow while skipping {}
• Failed to open file for resume {}: {}
• Failed to open file for append: {}
• Failed to open {} for resume: {}
• Progress byte count overflow

AI-assisted analysis of Zackriya-Solutions/meetily@a2cb62e827 (2026-09-12). Data as JSON: /api/errors/7b709b81ec3cb1bc. Report an issue: GitHub.