What causes "{provider_name} returned a result for a different operation" in astrid-runtime/astrid?

Fix the provider to return the outcome variant matching the request operation

{provider_name} returned a result for a different operation

Error message

{provider_name} returned a result for a different operation

What it means

validate_response verifies with a matches! guard that the response outcome corresponds to the request operation: a Mount request must yield a Mounted/Success outcome (or any Failure), Unmount must yield Unmounted, etc. If the outcome variant does not match the operation, the response is for a different operation and the CLI bails.

Source

Thrown at crates/astrid-cli/src/commands/storage.rs:256

    }
    let operation_matches = matches!(
        (&request.operation, &response.outcome),
        (
            StorageProviderOperationV1::Mount { .. },
            StorageProviderOutcomeV1::Success(StorageProviderSuccessV1::Mounted { .. })
        ) | (
            StorageProviderOperationV1::Sync { .. },
            StorageProviderOutcomeV1::Success(StorageProviderSuccessV1::Synced { .. })
        ) | (
            StorageProviderOperationV1::Status { .. },
            StorageProviderOutcomeV1::Success(StorageProviderSuccessV1::Status { .. })
        ) | (
            StorageProviderOperationV1::Unmount { .. },
            StorageProviderOutcomeV1::Success(StorageProviderSuccessV1::Unmounted { .. })
        ) | (_, StorageProviderOutcomeV1::Failure(_))
    );
    if !operation_matches {
        bail!("{provider_name} returned a result for a different operation");
    }
    match &response.outcome {
        StorageProviderOutcomeV1::Success(
            StorageProviderSuccessV1::Mounted { mountpoint, .. }
            | StorageProviderSuccessV1::Status { mountpoint, .. },
        ) => validate_response_mountpoint(provider_name, mountpoint),
        _ => Ok(()),
    }
}

fn validate_response_mountpoint(provider_name: &str, mountpoint: &Path) -> Result<()> {
    if !mountpoint.is_absolute()
        || mountpoint.components().any(|component| {
            matches!(
                component,
                std::path::Component::ParentDir | std::path::Component::CurDir
            )
        })

View on GitHub (pinned to affd8760f4)

Solutions

Fix the provider to return the outcome variant matching the request operation
Ensure strict request/response correlation (single in-flight request per provider process)
Rebuild the provider against the current V1 protocol definitions
Add a provider-side exhaustive match over StorageProviderOperationV1 returning the correct Success variant

Example fix

// before (provider)
let outcome = StorageProviderOutcomeV1::Success(StorageProviderSuccessV1::Unmounted { .. }); // for Mount
// after
let outcome = StorageProviderOutcomeV1::Success(StorageProviderSuccessV1::Mounted { mountpoint, .. });

Defensive patterns

Strategy: validation

Validate before calling

fn outcome_matches(op: &StorageProviderOperationV1, out: &StorageProviderOutcomeV1) -> bool { matches!((op, out), (StorageProviderOperationV1::Mount{..}, StorageProviderOutcomeV1::Success(StorageProviderSuccessV1::Mounted{..})) | (StorageProviderOperationV1::Unmount{..}, StorageProviderOutcomeV1::Success(StorageProviderSuccessV1::Unmounted{..})) | (_, StorageProviderOutcomeV1::Failure(_))) }

Type guard

fn is_success_for(op: &StorageProviderOperationV1, out: &StorageProviderOutcomeV1) -> bool { !matches!(out, StorageProviderOutcomeV1::Failure(_)) && outcome_matches(op, out) }

Try / catch

let resp = run_provider(req)?;
anyhow::ensure!(outcome_matches(&req.operation, &resp.outcome), "provider outcome/operation mismatch");

Prevention

Use one exhaustive match from operation to success variant in the provider
Keep one in-flight request per provider process
Regenerate provider code from the current V1 protocol definitions

When it happens

Trigger: Sending a Mount request but receiving StorageProviderSuccessV1::Unmounted (or vice versa), or an unexpected Success variant for the operation — caught by the operation_matches check in validate_response.

Common situations: Provider implementation maps operations to the wrong outcome variant; response/request streams crossed between concurrent provider calls; a provider written against an older protocol version returns a legacy outcome shape the matcher doesn't recognize.

Related errors

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