What causes "Download timeout - No data received for 30 seconds" in Zackriya-Solutions/meetily?

Retry the download — the engine resumes from the preserved partial file via Range instead of restarting

Download timeout - No data received for 30 seconds

Error message

Download timeout - No data received for 30 seconds

What it means

Every chunk read is wrapped in timeout(Duration::from_secs(30), stream.next()). This error means the HTTP connection stayed open but delivered zero bytes for 30 seconds — a stalled stream, not a dropped one. The engine flushes and keeps the partial file, resets model status to Missing, and removes it from active downloads so the same call can be retried with resume.

Source

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

                    Err(_) => {
                        log::warn!("Download timeout for {}: no data received for 30 seconds", model_name);
                        let _ = writer.flush().await;

                        // Remove from active downloads
                        {
                            let mut active = self.active_downloads.write().await;
                            active.remove(model_name);
                        }

                        // Update model status to Missing so retry can work
                        {
                            let mut models = self.available_models.write().await;
                            if let Some(model) = models.get_mut(model_name) {
                                model.status = ModelStatus::Missing;
                            }
                        }

                        return Err(anyhow!("Download timeout - No data received for 30 seconds"));
                    },
                    // Stream ended
                    Ok(None) => break,
                    // Got chunk result
                    Ok(Some(chunk_result)) => {
                        match chunk_result {
                            Ok(c) => c,
                            // Detect error type for better user feedback
                            Err(e) => {
                                log::error!("Download error for {}: {:?}", model_name, e);
                                let _ = writer.flush().await;

                                // Remove from active downloads
                                {
                                    let mut active = self.active_downloads.write().await;
                                    active.remove(model_name);
                                }

View on GitHub (pinned to 0281737d87)

Solutions

Retry the download — the engine resumes from the preserved partial file via Range instead of restarting
If it stalls repeatedly at the same byte offset, delete the partial file and retry fresh (corrupt resume state)
Check for interfering proxies/VPNs by downloading the same URL with curl -L -o /dev/null
If the network is known to be slow, raise the per-chunk timeout or add a low-speed abort policy instead of a hard 30 s

Defensive patterns

Strategy: retry

Validate before calling

// Cheap pre-flight: confirm the host streams data before committing to a long download
let resp = client.head(url).send().await?;
if !resp.status().is_success() { return Err(anyhow!("host unreachable")); }

Try / catch

let mut attempt = 0;
loop {
    match engine.download_model(name, cb).await {
        Err(e) if e.to_string().contains("Download timeout") && attempt < 3 => {
            attempt += 1;
            tokio::time::sleep(Duration::from_secs(2u64.pow(attempt))).await; // partial file resumes
        }
        other => break other,
    }
}

Prevention

Wrap downloads in a bounded retry with exponential backoff that exploits resume
Detect flaky networks early with a HEAD or small-range probe before large downloads
Run one model download at a time to reduce connection stalls

When it happens

Trigger: CDN/origin stalls mid-transfer with the socket open; captive portal or proxy that accepts the connection but never streams; Wi-Fi roaming or VPN rekey freezing the socket; server-side throttling that pauses the body after headers.

Common situations: Corporate proxies rate-limiting large files from HuggingFace; laptop switching networks mid-download; VPN dropout; origin server slow cold-start after a pause.

Understand the failure class

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

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