Zackriya-Solutions/meetily · error

Retry failed for {} with status: {}

Error message

Retry failed for {} with status: {}

What it means

Returned by download_model_detailed when the no-Range retry request completed but returned a non-success HTTP status. Unlike the initial path, the retry branch only checks is_success(), so any 4xx/5xx (403 forbidden, 404 gone, 429 rate limited, 5xx outage) lands here with the reqwest StatusCode printed.

Source

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

                        "File {} incomplete ({}/{} bytes). Deleting and retrying.",
                        filename, existing_size, expected_size
                    );

                    if let Err(e) = fs::remove_file(&file_path).await {
                        let mut active = self.active_downloads.write().await;
                        active.remove(model_name);
                        return Err(anyhow!("Failed to delete incomplete file {}: {}", filename, e));
                    }

                    // Retry without Range header
                    log::info!("Retrying {} without resume", filename);
                    response = client.get(&file_url).send().await
                        .map_err(|e| anyhow!("Retry failed for {}: {}", filename, e))?;

                    if !response.status().is_success() {
                        let mut active = self.active_downloads.write().await;
                        active.remove(model_name);
                        return Err(anyhow!("Retry failed for {} with status: {}", filename, response.status()));
                    }

                    (response.content_length().unwrap_or(0), false)
                }
            } else {
                // Other errors
                let mut active = self.active_downloads.write().await;
                active.remove(model_name);
                return Err(anyhow!("Download failed for {} with status: {}", filename, response.status()));
            };

            // Open file for writing (append if resuming, create new if not)
            let file = if resuming {
                fs::OpenOptions::new()
                    .append(true)
                    .open(&file_path)
                    .await
                    .map_err(|e| anyhow!("Failed to open file for resume {}: {}", filename, e))?

View on GitHub (pinned to 0281737d87)

Solutions

  1. On 429: wait several minutes before retrying the download (the partial file is kept and will resume)
  2. On 404/410: the upstream URL moved - update the app (base URLs are baked into parakeet_engine.rs) or fall back to the other model version whose host still serves it
  3. On 5xx: retry later; the mirror/CDN is having an incident
  4. Verify the exact file URL with curl -I to distinguish client-side blocks (403) from missing files (404)
Defensive patterns

Strategy: retry

Validate before calling

// Distinguish rate limits/outages from moved files before hammering the server
// v3 files: https://meetily.towardsgeneralintelligence.com/models/parakeet-tdt-0.6b-v3-onnx/<file>
// v2 files: https://huggingface.co/istupakov/parakeet-tdt-0.6b-v2-onnx/resolve/main/<file>
// A quick manual `curl -I <url>` tells you 429/5xx (retry later) from 404 (URL gone).

Try / catch

match engine.download_model(name, None).await {
    Err(e) if e.to_string().contains("Retry failed for") && e.to_string().contains("status") => {
        let msg = e.to_string();
        if msg.contains("429") || msg.contains("50") {
            // rate limit / origin outage: back off minutes, not seconds; resume keeps bytes
        } else if msg.contains("404") || msg.contains("403") {
            // upstream file gone/blocked: switch model version or update the app - do not retry
        }
        return Err(e);
    }
    other => other?,
}

Prevention

When it happens

Trigger: HuggingFace rate-limiting (429) after repeated large-file GETs on the retry; the file was removed upstream (404 on huggingface.co/istupakov/parakeet-tdt-0.6b-v2-onnx or the meetily mirror); origin returning 403 to the second request due to expired signed URL/auth; 502/503 from the CDN on failover.

Common situations: Repeated resume attempts hammering HuggingFace and hitting the rate limit; upstream repo reorganized so the hardcoded URL 404s; CDN incident at download time.

Related errors

AI-assisted analysis of Zackriya-Solutions/meetily@0281737d87 (2026-08-16). Data as JSON: /api/errors/137eb50cede35266. Report an issue: GitHub.