xai-org/grok-build · error

decode task panicked: {e}

Error message

decode task panicked: {e}

What it means

download_and_decode spawns a blocking task to decode a downloaded CLI artifact; this error is produced when that task panics (JoinError) instead of returning an Err. The temp binary file is deleted best-effort before returning. It signals the decode worker crashed — the artifact itself may be fine or corrupt; the panic obscured the reason.

Source

Thrown at crates/codegen/xai-grok-update/src/auto_update.rs:1403

        let mut capped = decoder.take(MAX_DECODED_BYTES + 1);
        let written = std::io::copy(&mut capped, &mut out).context("decode")?;
        if written > MAX_DECODED_BYTES {
            anyhow::bail!("decoded artifact exceeds the {MAX_DECODED_BYTES}-byte cap");
        }
        Ok(())
    })
    .await;
    let _ = tokio::fs::remove_file(&comp_tmp).await;

    match decoded {
        Ok(Ok(())) => publish_downloaded_artifact(&bin_tmp, dest).await,
        Ok(Err(e)) => {
            let _ = tokio::fs::remove_file(&bin_tmp).await;
            Err(e)
        }
        Err(e) => {
            let _ = tokio::fs::remove_file(&bin_tmp).await;
            Err(anyhow::anyhow!("decode task panicked: {e}"))
        }
    }
}

async fn download_cli_artifact_from_gcs(
    gcs_base_url: &str,
    object_name: &str,
    dest: &std::path::Path,
    with_progress: bool,
) -> Result<()> {
    let base = gcs_base_url.trim_end_matches('/');

    for (suffix, codec) in [("zst", Codec::Zstd), ("gz", Codec::Gzip)] {
        let url = format!("{base}/{object_name}.{suffix}");
        match download_and_decode(&url, dest, codec, with_progress).await {
            Ok(()) => return Ok(()),
            Err(e) => tracing::debug!("compressed .{suffix} unusable, trying next: {e}"),
        }

View on GitHub (pinned to bc7f02eddd)

Solutions

1. Read the embedded panic message to identify which decode step crashed
2. Delete any leftover bin_tmp file and retry the download (corrupt artifacts are removed automatically, verify bin_tmp is gone)
3. Check that the artifact served by GCS matches the expected codec/encoding
4. Retry the update — if the artifact is corrupted server-side, the round-trip test will also fail

// sanity-check the artifact before decoding
let meta = tokio::fs::metadata(&bin_tmp).await?;
if meta.len() == 0 { anyhow::bail!("downloaded artifact is empty"); }

match download_and_decode(&url, &dest, &codec).await {
    Err(e) if e.to_string().contains("decode task panicked") => {
        // remove leftover temp file and retry or fall back
        let _ = tokio::fs::remove_file(&bin_tmp).await;
        eprintln!("decode panicked: {e}");
    }
    Err(e) => return Err(e),
    Ok(()) => {}
}

When it happens

Trigger: Calling download_and_decode (via download_cli_artifact_from_gcs) when the spawned decode closure panics — e.g. unwrap on malformed archive data, out-of-bounds slicing while decoding a corrupt artifact, or the decoder library panicking on bad input.

Common situations: Corrupt or truncated artifact downloaded from GCS causing the decoder to panic on unexpected bytes; codec mismatch (file not in the expected codec format); OOM aborts surfacing as panics on huge artifacts.

Related errors

• blocking write task panicked: {e}
• Connection cancelled
• Task panicked: {}
• agent runtime worker join: {e}
• Authentication cancelled

AI-assisted analysis of xai-org/grok-build@bc7f02eddd (2026-08-31). Data as JSON: /api/errors/1e33e738f23f527b. Report an issue: GitHub.