What causes "unexpected env list response: {response:?}" in astrid-runtime/astrid?

Inspect the debug dump of {response:?} in the message to see which AdminResponseBody variant actually came back.

unexpected env list response: {response:?}

Error message

unexpected env list response: {response:?}

What it means

list_existing_keys calls the daemon/admin EnvList API and destructures the response with `let AdminResponseBody::EnvList(entries) = response else`. If the admin client returns any other AdminResponseBody variant, it bails with the debug dump of the response. It guards against the server/client disagreeing on the reply shape for an env-list request.

Source

Thrown at crates/astrid-cli/src/commands/capsule/install_daemon.rs:110

        )?
    };
    install_local_via_daemon_for_target(source, &vars, &principal, None, authority).await
}

async fn list_existing_keys(
    principal: &PrincipalId,
    capsule: &str,
) -> anyhow::Result<std::collections::HashSet<String>> {
    let mut client = crate::admin_client::connect_as_active_agent().await?;
    let response = client
        .request(AdminRequestKind::EnvList {
            principal: principal.clone(),
            capsule: Some(capsule.to_owned()),
        })
        .await?;
    let response = crate::admin_client::into_result(response)?;
    let AdminResponseBody::EnvList(entries) = response else {
        bail!("unexpected env list response: {response:?}");
    };
    Ok(entries.into_iter().map(|entry| entry.key).collect())
}

/// Install a local artifact into an explicit authenticated principal's
/// durable registry. The kernel enforces whether the caller may select that
/// target; this helper never opens the principal store itself.
pub(crate) async fn install_local_via_daemon_for_target(
    source: &str,
    vars: &[String],
    target: &PrincipalId,
    provenance: Option<CapsuleInstallProvenance>,
    authority: CapsuleInstallAuthority,
) -> anyhow::Result<InstalledCapsuleOutcome> {
    install_local_via_daemon_for_target_with_generation(
        source, vars, target, provenance, authority, None,
    )
    .await

View on GitHub (pinned to affd8760f4)

Solutions

Inspect the debug dump of {response:?} in the message to see which AdminResponseBody variant actually came back.
Restart/upgrade the astrid daemon so its version matches the CLI.
Re-authenticate or verify the principal/capsule sent in the AdminRequest are correct.
Run `crate::admin_client::into_result` semantics in mind: if this keeps firing, file a bug since into_result should have already converted error bodies.

Defensive patterns

Strategy: try-catch

Validate before calling

// before installing, check daemon/CLI versions match
astrid daemon version && astrid --version

Type guard

if let AdminResponseBody::EnvList(entries) = response { /* use entries */ } else { /* handle unexpected shape */ }

Try / catch

match anyhow result: on Err(e) if e.to_string().contains("unexpected env list response"), restart/upgrade the daemon and retry once; otherwise propagate.

Prevention

Keep CLI and daemon on the same release version.
Verify principal/capsule arguments before calling install.
Log the full response body when integrating with the daemon.

When it happens

Trigger: Calling install_local_via_daemon_outcome -> list_existing_keys when the daemon responds to an EnvList request with an error body, a differently-tagged AdminResponseBody variant, or a response from an incompatible daemon version.

Common situations: Daemon running an older/newer build with different response variants; request authenticated against the wrong principal/capsule so the daemon answers with an error; proxy or daemon returning a generic error body instead of EnvList.

Related errors

AI-assisted analysis of astrid-runtime/astrid@affd8760f4 (2026-09-09). Data as JSON: /api/errors/b9e2aeb6cab4fd61. Report an issue: GitHub.