Hmbown/CodeWhale · error · anyhow::Error

failed to download {url}

Error message

failed to download {url}

What it means

Defensive fallback arm of download_url's retry loop: returned only if the loop (1..=UPDATE_HTTP_ATTEMPTS, currently 3) finishes without recording an error. Every real failure carries the HTTP status or transport context; this message has no cause and is unreachable in shipped builds.

Source

Thrown at crates/cli/src/update.rs:1140

            Ok((status, bytes)) if status.is_success() => return Ok(bytes),
            Ok((status, bytes)) => {
                let body = String::from_utf8_lossy(&bytes);
                let error = anyhow!("download failed with HTTP {status}: {body}");
                if should_retry_http_status(status) && attempt < UPDATE_HTTP_ATTEMPTS {
                    last_error = Some(error);
                    sleep_before_update_retry(attempt);
                    continue;
                }
                return Err(error);
            }
            Err(error) if attempt < UPDATE_HTTP_ATTEMPTS => {
                last_error = Some(error);
                sleep_before_update_retry(attempt);
            }
            Err(error) => return Err(error),
        }
    }
    Err(last_error.unwrap_or_else(|| anyhow!("failed to download {url}")))
}

fn download_url_once(url: &str, proxy: Option<&Proxy>) -> Result<(reqwest::StatusCode, Vec<u8>)> {
    let client = update_http_client(proxy)?;
    let response = client
        .get(url)
        .send()
        .with_context(|| format!("failed to download {url}"))?;
    let status = response.status();
    let bytes = response
        .bytes()
        .with_context(|| format!("failed to read response body from {url}"))?;

    Ok((status, bytes.to_vec()))
}

/// Compute the SHA256 hex digest of data.
fn sha256_hex(data: &[u8]) -> String {

View on GitHub (pinned to 8880682c63)

Solutions

1. Treat as an internal invariant violation and report the build
2. If maintaining a fork, keep UPDATE_HTTP_ATTEMPTS >= 1
3. Diagnose the real failure from the preceding transport errors, not this message

Propagate as an internal error with no retry: the message has no attached cause, so any retry decision must come from the preceding transport errors in your own logs.

When it happens

Trigger: Only if UPDATE_HTTP_ATTEMPTS were 0 or the loop were rewritten; genuine download problems surface through the HTTP-status or transport arms with detailed messages.

Common situations: Practically none in shipped builds; it exists so the function is total for the compiler.

Related errors

• failed to fetch {description} from {url}
• failed to resolve latest stable release from {url}
• download failed with HTTP {status}: {body}
• Runtime API request failed (${status}): ${message}
• iLink API ${endpoint} failed: HTTP ${response.status} — ${te

AI-assisted analysis of Hmbown/CodeWhale@8880682c63 (2026-08-16). Data as JSON: /api/errors/335e9bbd1d0976bf. Report an issue: GitHub.