What causes "daemon rejected status request: {message}" in astrid-runtime/astrid?

Read the embedded {message} — it names the daemon-side reason and dictates the fix.

daemon rejected status request: {message}

Error message

daemon rejected status request: {message}

What it means

status_response maps the kernel's reply to a DaemonStatus. When the daemon answers the GetStatus request with KernelResponse::Error, the CLI surfaces the daemon-supplied reason verbatim prefixed with 'daemon rejected status request:'. The connection and protocol worked; the daemon itself refused to serve a status report.

Source

Thrown at crates/astrid-cli/src/commands/daemon.rs:651

    println!("  Capsules:   {} loaded", status.loaded_capsules.len());
    for capsule in &status.loaded_capsules {
        println!("    - {capsule}");
    }
    Ok(())
}

fn status_document(status: Option<&DaemonStatus>) -> serde_json::Value {
    status.map_or_else(
        || serde_json::json!({ "state": "stopped" }),
        |status| serde_json::json!({ "state": "running", "daemon": status }),
    )
}

fn status_response(response: KernelResponse) -> Result<DaemonStatus> {
    match response {
        KernelResponse::Status(status) => Ok(status),
        KernelResponse::Error(message) => {
            anyhow::bail!("daemon rejected status request: {message}")
        },
        other => anyhow::bail!("daemon returned an unexpected status response: {other:?}"),
    }
}

/// Handle `astrid stop`.
///
/// A shutdown request over the socket only earns an ACK ("shutting down"), not a
/// guarantee the process exited and released the singleton/state-db lock. So we
/// capture the recorded PID BEFORE asking, then confirm the process actually
/// exits — escalating with a signal if it wedges mid-shutdown — before reporting
/// success. Runtime files (socket, readiness, PID) are removed only once the
/// daemon is confirmed gone; if a kill can't confirm exit, they are LEFT so
/// `astrid start`/`restart` still see the recorded PID and give an actionable
/// message instead of failing on the held lock with a raw DB error.
pub(crate) async fn handle_stop() -> Result<()> {
    validate_runtime_admission()?;
    // A pre-lease gateway may legitimately hold the start fence while it boots

View on GitHub (pinned to affd8760f4)

Solutions

Read the embedded {message} — it names the daemon-side reason and dictates the fix.
Retry `astrid status` — transient rejections (e.g. brief lock contention) often clear.
Run `astrid restart` if the daemon is persistently degraded.
Check daemon logs for the matching internal error to fix the root cause.

Example fix

// before
let status = status_response(client.request(KernelRequest::GetStatus).await?)?;
// after (retry transient rejections)
let status = match client.request(KernelRequest::GetStatus).await {
    Ok(r @ KernelResponse::Status(_)) => status_response(r)?,
    Ok(KernelResponse::Error(msg)) => { tokio::time::sleep(Duration::from_secs(1)).await; status_response(client.request(KernelRequest::GetStatus).await?)? }
    other => status_response(other?)?,
};

Defensive patterns

Strategy: try-catch

Validate before calling

null

Type guard

fn status_of(resp: &KernelResponse) -> Option<&DaemonStatus> {
    match resp { KernelResponse::Status(s) => Some(s), _ => None }
}

Try / catch

let resp = client.request(KernelRequest::GetStatus).await?;
let status = match status_response(resp) {
    Ok(s) => s,
    Err(e) if e.to_string().starts_with("daemon rejected status request") => {
        eprintln!("daemon degraded: {e}; retrying or restarting");
        run(vec!["astrid", "restart"])?;
        status_response(client.request(KernelRequest::GetStatus).await?)?
    }
    Err(e) => return Err(e),
};

Prevention

Watch daemon logs — the embedded message names the internal handler that rejected the query.
Avoid querying status during startup/shutdown windows; wait for readiness markers.
Keep daemon and CLI versions aligned to reduce degraded-handler states.
Retry once before restarting: many rejections are transient lock contention.

When it happens

Trigger: Sending KernelRequest::GetStatus over the socket and receiving KernelResponse::Error(message) from the daemon — i.e. the daemon's request handler explicitly rejected the status query with some internal reason string.

Common situations: Daemon degraded state (state DB locked, capsule load failure, internal handler error) at the moment status was queried; daemon built from a mismatched version with runtime invariants failing; querying during shutdown when handlers already began unwinding.

Related errors

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