What causes "unexpected daemon response: {other:?}" in astrid-runtime/astrid?

Check the {other:?} dump to identify the unexpected KernelResponse variant.

unexpected daemon response: {other:?}

Error message

unexpected daemon response: {other:?}

What it means

The catch-all arm of the KernelResponse match in install_local_via_daemon_for_target_with_generation. Any daemon reply that is neither the expected success shape nor KernelResponse::Error bails with a debug dump of the reply. This protects the install flow from protocol desynchronization.

Source

Thrown at crates/astrid-cli/src/commands/capsule/install_daemon.rs:246

            }
            let version = output
                .get("installed_version")
                .and_then(serde_json::Value::as_str)
                .unwrap_or(manifest.package.version.as_str())
                .to_owned();
            let wasm_hash = output
                .get("wasm_hash")
                .and_then(serde_json::Value::as_str)
                .map(str::to_owned);
            Ok(InstalledCapsuleOutcome {
                id: capsule_id,
                version,
                wasm_hash,
                skipped: false,
            })
        },
        KernelResponse::Error(message) => bail!("daemon rejected capsule install: {message}"),
        other => bail!("unexpected daemon response: {other:?}"),
    }
}

fn resume_generation_from_receipt(
    receipt: Option<CapsuleInstallResumeReceipt>,
    expected_id: &CapsuleId,
    source_digest: &str,
    expected_generation_hint: Option<&InstalledCapsuleGeneration>,
) -> Option<InstalledCapsuleGeneration> {
    let receipt = receipt?;
    if receipt.id != expected_id.as_str()
        || !is_digest(source_digest)
        || receipt.archive_digest != source_digest
        || !is_generation_well_formed(&receipt.generation)
        || expected_generation_hint.is_some_and(|hint| hint != &receipt.generation)
    {
        return None;
    }

View on GitHub (pinned to affd8760f4)

Solutions

Check the {other:?} dump to identify the unexpected KernelResponse variant.
Align CLI and daemon versions (upgrade both to the same release).
Retry the install on a fresh daemon connection.
If the variant is legitimate, report/patch the match to handle it.

Defensive patterns

Strategy: type-guard

Type guard

fn is_expected_kernel_response(r: &KernelResponse) -> bool { matches!(r, KernelResponse::Installed{..} | KernelResponse::Error(_)) }

Try / catch

on 'unexpected daemon response', restart the daemon connection and retry once; if it persists, capture the {other:?} dump for a bug report.

Prevention

Upgrade CLI and daemon together.
Avoid sharing one daemon connection across concurrent installs.
Keep KernelResponse handling exhaustive with a default that logs the variant.

When it happens

Trigger: install_local_via_daemon_for_target receives a KernelResponse variant the install handler doesn't recognize (e.g. a progress/intermediate response, or a response added by a newer daemon).

Common situations: Daemon and CLI version skew introducing new KernelResponse variants; misrouted responses from a shared daemon connection; bug in request routing returning the wrong reply type.

Related errors

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