zeroclaw-labs/zeroclaw · error · anyhow::Error

elicitation returned unknown choice const: {s}

Error message

elicitation returned unknown choice const: {s}

What it means

download_release (src/commands/update.rs:430) GETs the release asset URL (browser_download_url taken from the GitHub release metadata during check()) with a 5-minute timeout and bails on any non-2xx status, echoing the raw status. This is Phase 2 of `zeroclaw update`; nothing is installed when it fires. A 404 usually means the asset disappeared or was renamed after the API snapshot; 403/429 are rate limiting; 5xx are CDN-side.

Source

Thrown at crates/zeroclaw-api/src/elicitation.rs:237

pub fn decode_multi_select_accept(
    content: &Value,
    choices: &[String],
) -> anyhow::Result<Vec<String>> {
    let arr = content
        .get("choices")
        .and_then(|v| v.as_array())
        .ok_or_else(|| anyhow::Error::msg("elicitation accept missing content.choices array"))?;
    let mut out = Vec::with_capacity(arr.len());
    for v in arr {
        let s = v
            .as_str()
            .ok_or_else(|| anyhow::Error::msg("non-string entry in content.choices"))?;
        let idx = s
            .strip_prefix("choice-")
            .and_then(|n| n.parse::<usize>().ok());
        match idx.and_then(|i| choices.get(i)) {
            Some(text) => out.push(text.clone()),
            None => anyhow::bail!("elicitation returned unknown choice const: {s}"),
        }
    }
    Ok(out)
}

#[cfg(test)]
mod tests {
    use super::*;
    use serde_json::json;

    #[test]
    fn missing_key_is_no_support() {
        let caps = ElicitationCapabilities::from_value(None);
        assert!(!caps.form);
        assert!(!caps.url);
    }

    #[test]

View on GitHub (pinned to 88bb9c8533)

Solutions

  1. Verify the asset still exists on the release page (matching your target triple), then re-run `zeroclaw update` to get fresh metadata
  2. If rate-limited (403/429), wait out the window and retry
  3. Configure HTTPS_PROXY correctly or temporarily bypass the proxy for github.com / objects.githubusercontent.com
  4. If the asset is genuinely gone from the release, report it and update to a different tag with --version

Example fix

# before
$ zeroclaw update
Error: download returned 404 Not Found

# after
$ # confirm the asset for your target triple exists on the release page
$ curl -fsSI "https://github.com/zeroclaw-labs/zeroclaw/releases/download/<tag>/zeroclaw-x86_64-unknown-linux-gnu.tar.gz"
$ zeroclaw update   # retries with fresh release metadata
Defensive patterns

Strategy: retry

Validate before calling

// Preflight: HEAD the asset URL before committing to the update.
async fn asset_fetchable(client: &reqwest::Client, url: &str) -> bool {
    client
        .head(url)
        .send()
        .await
        .map(|r| r.status().is_success())
        .unwrap_or(false)
}

Try / catch

match update::run(version, force).await {
    Err(e) if e.to_string().contains("download returned 404") => {
        // Permanent-ish: re-run check() for fresh asset metadata; if the
        // asset is truly gone from the release, pin another --version.
    }
    Err(e) if e.to_string().contains("download returned 403")
            || e.to_string().contains("download returned 429") => {
        // Rate limited: back off and retry once later.
    }
    other => other,
}

Prevention

When it happens

Trigger: `zeroclaw update` downloading the platform archive (zeroclaw-<triple>.tar.gz / .zip) when the asset fetch fails: asset deleted or replaced after the metadata was fetched, GitHub CDN rate limit (shared egress IP), or a proxy/firewall blocking objects.githubusercontent.com with an error status.

Common situations: Corporate proxy or TLS-inspecting middlebox answering 403 for the CDN host; CI runner behind NAT hitting rate limits; a release yanked or its assets re-uploaded mid-update.

Related errors

AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23). Data as JSON: /api/errors/149c37e9318cf839. Report an issue: GitHub.