astrid-runtime/astrid · error
daemon rejected readiness query
Error message
daemon rejected readiness query: {msg} What it means
When the daemon answers GetAgentReadiness with KernelResponse::Error, the inner message is surfaced as 'daemon rejected readiness query: {msg}'. The request and response round-tripped fine; the daemon itself refused the readiness computation or reported an application-level failure.
Solutions
- Read the interpolated {msg} for the daemon's underlying failure reason
- Fix the workspace/kernel state indicated by the inner message
- Restart the daemon to clear bad in-memory state
- Add logging around the daemon's readiness evaluator to capture the root cause
Defensive patterns
Strategy: try-catch
Try / catch
match agent_readiness().await {
Err(e) if e.to_string().starts_with("daemon rejected readiness query") => {
// surface the inner daemon message; inspect daemon logs
eprintln!("{e:#}");
}
other => other?,
} Prevention
- Keep workspace/kernel state valid and initialized
- Check daemon logs for the inner failure reason
- Restart the daemon after version upgrades
- Run doctor regularly to catch state corruption early
When it happens
Trigger: The daemon returns KernelResponse::Error(msg) for a GetAgentReadiness request — e.g. its internal readiness evaluation failed, the workspace state is invalid, or the daemon lacks required state to evaluate agent-loop readiness.
Common situations: Corrupt or partially-initialized workspace state on the daemon; daemon running against an incompatible store; internal daemon error while checking configured interfaces.
Related errors
- daemon did not return an agent-readiness response
- Admin request timed out after
- an Astrid daemon appears to be running but its uplink is…
- an Astrid daemon appears to be running but its uplink is…
- an Astrid daemon is recorded as running (PID file) but its…
AI-assisted analysis of astrid-runtime/astrid@affd8760f4 (2026-09-09).
Data as JSON: /api/errors/607782dfb91dbbb5.
Report an issue: GitHub.
Appendix: source
Thrown at crates/astrid-cli/src/commands/doctor.rs:269
/// other daemon-dependent checks use. Rides the existing
/// `astrid.v1.request.` ingress allowlist prefix — no capsule change needed.
async fn agent_readiness() -> Result<astrid_core::kernel_api::AgentLoopReadiness> {
let mut client = tokio::time::timeout(
Duration::from_secs(5),
crate::socket_client::connect_kernel_for_workspace(None),
)
.await
.map_err(|_| anyhow::anyhow!("connection timed out after 5s"))??;
match tokio::time::timeout(
Duration::from_secs(5),
client.request(KernelRequest::GetAgentReadiness),
)
.await
.map_err(|_| anyhow::anyhow!("daemon response timed out after 5s"))??
{
KernelResponse::AgentReadiness(readiness) => Ok(readiness),
KernelResponse::Error(msg) => {
Err(anyhow::anyhow!("daemon rejected readiness query: {msg}"))
},
_ => Err(anyhow::anyhow!(
"daemon did not return an agent-readiness response"
)),
}
}
async fn projection_name_diagnostic(
policy: ProjectionNamePolicyPreset,
) -> Result<ProjectionNameDiagnostic> {
let mut client = tokio::time::timeout(
Duration::from_secs(5),
crate::socket_client::connect_kernel_for_workspace(None),
)
.await
.map_err(|_| anyhow::anyhow!("connection timed out after 5s"))??;
tokio::time::timeout(
Duration::from_secs(30),View on GitHub (pinned to affd8760f4)