astrid-runtime/astrid · error
daemon rejected capsule metadata request: {message}
Error message
daemon rejected capsule metadata request: {message} What it means
Raised by `daemon_capsule_metadata` when the running astrid daemon answers a `GetCapsuleMetadata` request with a `KernelResponse::Error(message)` instead of capsule metadata. The daemon's own rejection reason is embedded in the message, so the root cause (auth, state, internal daemon failure) comes from the daemon side. Called by `update_daemon_capsules` and `regenerate_distro_lock`.
Source
Thrown at crates/astrid-cli/src/commands/capsule/install_update.rs:178
&source,
Some(name),
workspace,
false,
approve_untrusted,
&[],
)
.await
} else {
update_all_capsules(&home, &principal, workspace, approve_untrusted).await
}
}
async fn daemon_capsule_metadata() -> anyhow::Result<Vec<CapsuleMetadataEntry>> {
let mut client = crate::socket_client::connect_kernel_for_workspace(None).await?;
match client.request(KernelRequest::GetCapsuleMetadata).await? {
KernelResponse::CapsuleMetadata(entries) => Ok(entries),
KernelResponse::Error(message) => {
bail!("daemon rejected capsule metadata request: {message}")
},
other => bail!("unexpected daemon response: {other:?}"),
}
}
async fn update_daemon_capsules(
target: Option<&str>,
principal: &astrid_core::PrincipalId,
approve_untrusted: bool,
) -> anyhow::Result<()> {
let entries = daemon_capsule_metadata().await?;
if let Some(name) = target {
let entry = entries
.into_iter()
.find(|entry| entry.name == name)
.ok_or_else(|| anyhow::anyhow!("Capsule '{name}' is not installed."))?;
let Some(source) = entry.update_source else {
eprintln!(View on GitHub (pinned to affd8760f4)
Solutions
- Read the daemon's reason embedded in the message and address it directly.
- Restart the daemon so it rebuilds its capsule metadata state, then retry.
- Ensure the daemon and CLI versions match; upgrade the daemon after a CLI upgrade.
- If the metadata store is corrupt, reinstall the affected capsules to rebuild daemon-side metadata.
Example fix
// before: daemon started before CLI upgrade, rejects request astrid capsule update // error: daemon rejected capsule metadata request: unsupported request version // after: restart/upgrade the daemon to match the CLI astrid daemon restart astrid capsule update
Defensive patterns
Strategy: try-catch
Try / catch
match daemon_capsule_metadata().await {
Ok(entries) => update_all(entries),
Err(e) if e.to_string().starts_with("daemon rejected capsule metadata request") => {
eprintln!("{e:#}\nHint: restart the daemon and ensure CLI/daemon versions match.");
std::process::exit(1);
},
Err(e) => return Err(e),
} Prevention
- Always upgrade the daemon together with the CLI to avoid protocol skew.
- Restart the daemon after upgrades so stale state does not poison metadata responses.
- Monitor daemon logs for metadata-request errors before batch updates.
- Read the embedded daemon reason — it names the actual server-side cause.
When it happens
Trigger: Running `astrid capsule update` (non-workspace mode) or refreshing the distro lock when the daemon responds Error to `KernelRequest::GetCapsuleMetadata` — e.g. daemon's capsule registry is in a bad state, permissions failure, or an internal daemon error string.
Common situations: Daemon version mismatch with the CLI sending a request it mishandles; daemon's metadata store corrupted or unreadable; daemon not fully initialized after start; version-skew after an upgrade where the old daemon rejects new request semantics.
Related errors
- daemon rejected capsule metadata request: {message}
- an Astrid daemon appears to be running but its uplink is unr
- an Astrid daemon appears to be running but its uplink is unr
- daemon metadata lookup failed: {error}
- unexpected daemon metadata response: {other:?}
AI-assisted analysis of astrid-runtime/astrid@affd8760f4 (2026-09-09).
Data as JSON: /api/errors/53a7daa92cbbace9.
Report an issue: GitHub.