kernel returned an unexpected storage lifecycle response

Error message

kernel returned an unexpected storage lifecycle response

What it means

Thrown by `into_success` when the kernel's reply to a storage lifecycle request is neither `Success` nor `Error`. Like its mount counterpart, it indicates the provider received an unrecognized response variant and cannot interpret the outcome of the operation, so it fails fast rather than guessing success.

Source

Thrown at crates/astrid-storage-provider-winfsp/src/main.rs:317

        mount_id: record.mount_id,
    })
}

fn lease_from_response(body: AdminResponseBody) -> Result<StorageMountLeaseV1> {
    match body {
        AdminResponseBody::StorageMountLease(lease) => Ok(*lease),
        AdminResponseBody::Error(error) => bail!("kernel refused storage mount: {error}"),
        _ => bail!("kernel returned an unexpected storage mount response"),
    }
}

fn into_success(body: AdminResponseBody) -> Result<serde_json::Value> {
    match body {
        AdminResponseBody::Success(value) => Ok(value),
        AdminResponseBody::Error(error) => {
            bail!("kernel refused storage lifecycle request: {error}")
        },
        _ => bail!("kernel returned an unexpected storage lifecycle response"),
    }
}

fn unmount_status(body: AdminResponseBody) -> Result<bool> {
    match body {
        AdminResponseBody::Success(_) => Ok(true),
        AdminResponseBody::Error(error)
            if error.contains("was not found") || error.contains("expired or revoked") =>
        {
            Ok(false)
        },
        AdminResponseBody::Error(error) => {
            bail!("kernel refused storage unmount authorization: {error}")
        },
        _ => bail!("kernel returned an unexpected storage unmount response"),
    }
}

View on GitHub (pinned to affd8760f4)

Solutions

Align provider and kernel versions so the expected `AdminResponseBody` variants match
Inspect kernel logs/protocol traces to identify which response variant was actually returned
Update the provider's match arms to deserialize the new response variant

Defensive patterns

Strategy: try-catch

Type guard

fn is_interpretable(body: &AdminResponseBody) -> bool {
    matches!(body, AdminResponseBody::Success(_) | AdminResponseBody::Error(_))
}

Try / catch

match provider.execute(action).await {
    Ok(value) => handle(value),
    Err(e) if e.to_string().contains("unexpected storage lifecycle response") => {
        // treat as version-skew incident: alert and skip state mutation
    },
    Err(e) => return Err(e.into()),
}

Prevention

Keep provider and kernel builds in lockstep
Test lifecycle flows against every kernel release before rollout
Handle unknown AdminResponseBody variants explicitly in downstream tooling

When it happens

Trigger: `execute` or `unmount` issue a lifecycle admin request and the kernel answers with any `AdminResponseBody` variant other than `Success` or `Error` (e.g. a `StorageMountLease` payload or an unknown new variant).

Common situations: Kernel/provider version skew where the endpoint now returns a richer response type; calling a lifecycle endpoint that returns operation-specific payloads rather than generic success; misrouted requests hitting the mount-lease endpoint instead of the generic lifecycle one.

Understand the failure class

Background: "invalid response format", "malformed payload", "missing data field": when an API returns 200 but the response shape is wrong — this error's family across 23 libraries.

Related errors

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