astrid-runtime/astrid · error

unexpected response from kernel: {other:?}

Error message

unexpected response from kernel: {other:?}

What it means

`classify_secret_delete_response` maps an EnvDelete reply to a SecretDeleteProbe, accepting `Success` (and presumably PermissionDenied) variants. Any other AdminResponseBody variant bails with this message showing the body. Callers run_delete and several tests rely on this classification.

Source

Thrown at crates/astrid-cli/src/commands/secret.rs:444

/// after a successful agent-scoped delete.
fn classify_secret_delete_response(
    scope: EnvStorageScope,
    body: AdminResponseBody,
) -> Result<SecretDeleteProbe> {
    match body {
        AdminResponseBody::Error(msg)
            if scope == EnvStorageScope::Shared && msg.contains("permission denied") =>
        {
            Ok(SecretDeleteProbe::SharedUnauthorized)
        },
        AdminResponseBody::Error(msg) => Err(anyhow::anyhow!("kernel rejected request: {msg}")),
        AdminResponseBody::Success(value) => Ok(SecretDeleteProbe::Deleted(
            value
                .get("deleted")
                .and_then(serde_json::Value::as_bool)
                .unwrap_or(false),
        )),
        other => anyhow::bail!("unexpected response from kernel: {other:?}"),
    }
}

async fn run_delete(args: &DeleteArgs) -> Result<ExitCode> {
    let principal = context::resolve_agent(args.agent.as_deref())?;
    let capsule = validate_optional_capsule(args.capsule.as_deref())?;
    let kind = capsule_env_kind(&capsule, &args.key)
        .await?
        .unwrap_or(EnvValueKind::Text);
    let mut client = crate::admin_client::connect_as_active_agent().await?;
    let scopes = if matches!(kind, EnvValueKind::Secret) {
        vec![EnvStorageScope::Agent, EnvStorageScope::Shared]
    } else {
        vec![EnvStorageScope::Agent]
    };
    let mut removed = false;
    for scope in scopes {
        let body = client

View on GitHub (pinned to affd8760f4)

Solutions

1. Restart the daemon and CLI from the same build/commit.
2. Read the `{other:?}` payload to identify the unexpected variant and handle it explicitly in classify_secret_delete_response.
3. Confirm the delete request goes to the real astrid kernel admin service, not a proxy.
4. Update test fixtures/mocks to produce current AdminResponseBody variants.

Example fix

// before
other => anyhow::bail!("unexpected response from kernel: {other:?}"),
// after
AdminResponseBody::Error(e) => anyhow::bail!("daemon delete failed: {e}"),
other => anyhow::bail!("unexpected response from kernel: {other:?}"),

fn is_delete_probe_ok(body: &AdminResponseBody) -> bool {
    matches!(body, AdminResponseBody::Success(_) | AdminResponseBody::PermissionDenied)
}

match classify_secret_delete_response(body).await {
    Ok(probe) => handle(probe),
    Err(e) if e.to_string().contains("unexpected response from kernel") => {
        eprintln!("CLI/daemon mismatch? upgrade both and retry");
    }
    Err(e) => return Err(e),
}

When it happens

Trigger: `astrid secret delete` (or the tests agent_permission_denial_still_fails_secret_delete / shared_validation_errors_still_fail_secret_delete) when the kernel returns a variant other than Success/PermissionDenied for the delete request — e.g. version-skewed daemon replying with a new or different body type.

Common situations: Daemon/CLI version mismatch after an AdminResponseBody enum change; wrong admin endpoint returning unexpected payloads; test fixtures emitting a stale response variant.

Related errors

• unexpected response from kernel: {body:?}
• unexpected daemon metadata response: {other:?}
• daemon returned an unexpected status response
• unexpected response from kernel: {other:?}
• unexpected response from kernel: {other:?}

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