What causes "kernel rejected request: {msg}" in astrid-runtime/astrid?

Read the embedded `{msg}` from the kernel — it states the concrete rejection reason; fix the admin request accordingly.

kernel rejected request: {msg}

Error message

kernel rejected request: {msg}

What it means

Raised by the public helper `into_result` in `astrid-uplink/src/admin_client.rs:288`, which normalizes admin-plane IPC responses: when the kernel answers an admin request with `AdminResponseBody::Error(msg)`, the message is wrapped into an `anyhow` error. This is the standard conversion point at which a server-side rejection becomes a Rust `Result::Err` for the caller.

Source

Thrown at crates/astrid-uplink/src/admin_client.rs:288

            request_id: Some(request_id.clone()),
            request,
        })
        .context("Failed to serialize AgentDeriveKernelRequest")?;
        self.send_and_wait(topic, want_response, request_id, payload)
            .await
    }
}

/// Convert an [`AdminResponseBody`] into a `Result`, lifting `Error`
/// variants into `Err` so the caller can use `?` for cross-tenant
/// permission denials and validation failures.
///
/// # Errors
/// Returns an error wrapping the kernel's error message when the
/// response body is [`AdminResponseBody::Error`].
pub fn into_result(body: AdminResponseBody) -> Result<AdminResponseBody> {
    match body {
        AdminResponseBody::Error(msg) => Err(anyhow!("kernel rejected request: {msg}")),
        other => Ok(other),
    }
}

#[cfg(test)]
mod tests {
    use super::*;
    use astrid_core::PrincipalId;

    #[test]
    fn topic_suffixes_match_kernel_constants() {
        assert_eq!(
            topic_suffix(&AdminRequestKind::AgentCreate {
                name: "x".into(),
                groups: vec![],
                grants: vec![],
                inherit_from: None,
                clone_from: None,

View on GitHub (pinned to affd8760f4)

Solutions

Read the embedded `{msg}` from the kernel — it states the concrete rejection reason; fix the admin request accordingly.
Verify client and kernel versions match; re-run after upgrading the astrid daemon/client to the same release.
Check the session token/permissions for the requested admin operation.
Confirm the admin command name and payload shape against the current AdminResponseBody schema.
Match on the message text or retry with corrected arguments rather than blind retries — this error is deterministic, not transient.

Example fix

// before
let resp = kernel_round_trip(message).await?;
let value = admin_client::into_result(resp)?;
// after
let resp = kernel_round_trip(message).await?;
let value = admin_client::into_result(resp).map_err(|e| {
    eprintln!("admin request rejected by kernel: {e:#}");
    e
})?;

Defensive patterns

Strategy: try-catch

Validate before calling

// Validate the admin request before sending
ensure!(!command.is_empty(), "admin command must not be empty");
// confirm the kernel advertises support for the admin command, if such a capability call exists

Type guard

fn is_error_body(body: &AdminResponseBody) -> Option<&str> {
    match body {
        AdminResponseBody::Error(msg) => Some(msg),
        _ => None,
    }
}

Try / catch

let body = admin_client::into_result(resp).map_err(|e| {
    eprintln!("kernel rejected admin request: {e:#}");
    e
})?;

Prevention

Keep the admin client and kernel daemon on matching versions.
Validate admin command names and payload shapes against the current schema before sending.
Handle the error body explicitly instead of assuming success responses.
Check session permissions for privileged admin operations up front.

When it happens

Trigger: Specifically: calling `into_result(body)` where `body` is `AdminResponseBody::Error(msg)`. The kernel processed an admin request over the IPC channel but rejected it, returning an error body instead of a success payload (e.g. unknown admin command, invalid arguments, unauthorized operation).

Common situations: Administrative commands issued against a kernel that disagrees on the request schema (version skew between client and daemon); an admin action the current session token is not permitted to perform; a typo'd or unsupported admin verb; the kernel rejecting a request whose parameters violate kernel-side validation.

Understand the failure class

Background: "API error: {status}" and "HTTP 401/403/404/429/5xx" errors: non-2xx HTTP responses explained — this error's family across 27 libraries.

Related errors

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