astrid-runtime/astrid · error

unexpected response while resolving principal UID: {body:?}

Error message

unexpected response while resolving principal UID: {body:?}

What it means

resolve_principal_uid asks the admin daemon for the agent list to map a principal to its durable UID. If the daemon returns a response body whose variant is not AgentList, the CLI cannot interpret it and throws this error — usually indicating a protocol/version mismatch between CLI and daemon.

Source

Thrown at crates/astrid-cli/src/commands/logs.rs:64

        let entry = entry?;
        let path = entry.path();
        if !path.is_file() {
            continue;
        }
        let modified = entry.metadata()?.modified()?;
        if newest.as_ref().is_none_or(|(t, _)| *t < modified) {
            newest = Some((modified, path));
        }
    }
    Ok(newest.map(|(_, p)| p))
}

async fn resolve_principal_uid(principal: &PrincipalId) -> Result<PrincipalUid> {
    let mut client = crate::admin_client::connect_as_active_agent().await?;
    let body = client.request(AdminRequestKind::AgentList).await?;
    let body = crate::admin_client::into_result(body)?;
    let AdminResponseBody::AgentList(entries) = body else {
        anyhow::bail!("unexpected response while resolving principal UID: {body:?}");
    };
    entries
        .into_iter()
        .find(|entry| entry.principal == *principal)
        .and_then(|entry| entry.owner_uid)
        .ok_or_else(|| anyhow::anyhow!("principal '{principal}' has no admitted durable UID"))
}

async fn resolve_log_dir(principal: &PrincipalId, capsule: Option<&str>) -> Result<PathBuf> {
    let home = AstridHome::resolve().context("Failed to resolve Astrid home directory")?;
    Ok(match capsule {
        // Capsule runtime logs are operational state, not home content. The
        // daemon's immutable-UID projection owns the canonical path; resolve
        // the UID through the authenticated admin roster before reading it.
        Some(name) => home
            .log_dir()
            .join("principals")
            .join(resolve_principal_uid(principal).await?.to_string())

View on GitHub (pinned to affd8760f4)

Solutions

1. Restart the admin daemon and retry the command
2. Upgrade the CLI and daemon to matching versions
3. Check that the CLI's admin endpoint config points at the correct astrid admin daemon

Example fix

// before
# CLI v2 -> daemon v1
$ aos logs --principal alice
// after
$ aos version && aos daemon version  # align both, restart daemon
$ aos logs --principal alice

// Verify daemon reachability and version parity before the call
assert!(admin_daemon_reachable());
assert_eq!(cli_version(), daemon_version());

if let AdminResponseBody::AgentList(entries) = body { /* proceed */ } else { /* version mismatch */ }

match resolve_principal_uid(&principal).await {
    Err(e) if e.to_string().contains("unexpected response") => {
        // restart/upgrade daemon, then retry once
    }
    other => other,
}

When it happens

Trigger: `aos logs` resolving a log directory when the admin daemon replies to AgentList with a different AdminResponseBody variant (wrong daemon version, request routed to a non-agent-list endpoint, or corrupted response).

Common situations: Running a newer CLI against an older daemon (or vice versa); pointing the CLI at a different admin service that answers differently; a proxy/middleware rewriting responses.

Related errors

• unexpected daemon metadata response: {other:?}
• unexpected distro lock response: {other:?}
• daemon metadata lookup failed: {error}
• unexpected env list response: {response:?}
• daemon rejected capsule install: {message}

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