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

Read the embedded `{msg}` for the kernel's concrete reason and correct the 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/kernel_client.rs:470`, which converts a `KernelResponse` into a `Result`: the `KernelResponse::Error(msg)` variant becomes an `anyhow` error carrying the kernel's message. This is the generic kernel-plane counterpart to the admin_client conversion and is the point where server-side rejections surface as `Err` to all `request()`-style callers.

Source

Thrown at crates/astrid-uplink/src/kernel_client.rs:470

    #[cfg(all(test, unix))]
    fn from_socket_for_test(inner: SocketClient, caller: PrincipalId, timeout: Duration) -> Self {
        Self {
            inner,
            caller,
            timeout,
            device_key_id: None,
        }
    }
}

/// Convenience: lift a [`KernelResponse::Error`] into `Err`.
///
/// # Errors
/// Returns an error wrapping the kernel's error message when the
/// response is `KernelResponse::Error`.
pub fn into_result(resp: KernelResponse) -> Result<KernelResponse> {
    match resp {
        KernelResponse::Error(msg) => Err(anyhow!("kernel rejected request: {msg}")),
        other => Ok(other),
    }
}

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

    #[test]
    fn topic_suffixes_match_cli_conventions() {
        // Pin these to the strings the CLI's existing kernel-request
        // code already uses (who.rs, daemon.rs, ps.rs, doctor.rs).
        // Drift here means the gateway and CLI publish to different
        // topics for the same payload — silent breakage.
        assert_eq!(topic_suffix(&KernelRequest::GetStatus), "status");
        assert_eq!(topic_suffix(&KernelRequest::ListCapsules), "list_capsules");
        assert_eq!(topic_suffix(&KernelRequest::GetCommands), "get_commands");
        assert_eq!(topic_suffix(&KernelRequest::GetCapsuleMetadata), "metadata");

View on GitHub (pinned to affd8760f4)

Solutions

Read the embedded `{msg}` for the kernel's concrete reason and correct the request accordingly.
Match client and kernel versions; re-run after aligning the deployment.
Validate entity names/payload shape client-side before sending (e.g. check the projection exists).
Check session/token state if the message indicates authorization failure, then reconnect and re-authenticate.
Avoid blanket retries — treat this as a deterministic rejection unless the message indicates a transient kernel condition.

Example fix

// before
let resp = client.request(message).await?;
// after
let resp = client.request(message).await?;
let resp = kernel_client::into_result(resp).map_err(|e| {
    warn!(error = %e, "kernel rejected request");
    e
})?;

Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-validate the request payload against the kernel schema before send
serde_json::to_value(&request).context("request must serialize to the kernel schema")?;

Type guard

fn kernel_err(resp: &KernelResponse) -> Option<&str> {
    match resp {
        KernelResponse::Error(msg) => Some(msg),
        _ => None,
    }
}

Try / catch

let resp = kernel_client::into_result(client.request(message).await?)
    .map_err(|e| anyhow!("kernel call failed: {e:#}"))?;

Prevention

Always route kernel replies through `into_result` rather than matching Success manually.
Validate entity names and payload shape before sending requests.
Keep client/kernel versions synchronized.
Differentiate deterministic rejections from transient failures before deciding to retry.

When it happens

Trigger: Specifically: calling `into_result(resp)` where `resp` is `KernelResponse::Error(msg)`. Any kernel request (via `KernelClient::request` or `request_with_ceiling`) that the kernel answers with an error frame — bad arguments, unknown projection, denied operation, internal kernel error — produces this.

Common situations: Requesting an operation against a kernel that doesn't support it (version skew); malformed request payloads rejected by kernel validation; operating on entities that don't exist on the kernel; permission or session-state problems; kernel under load returning explicit failures.

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/3e840515abc91243. Report an issue: GitHub.