vllm-project/vllm · error · Error

utility call `{method}` returned an invalid result (call_id=

Error message

utility call `{method}` returned an invalid result (call_id={call_id}): {message}

What it means

EngineCoreError::UtilityResultDecode means the engine-core answered a utility call, but the returned payload could not be decoded into the expected result type (message carries the decode error). This is a serialization/contract problem between the two processes, not a user-input error.

Source

Thrown at rust/src/engine-core-client/src/error.rs:90

        "data parallel rank {rank} is not connected to this frontend; connected ranks: {connected_ranks:?}"
    )]
    InvalidDataParallelRank {
        rank: u32,
        connected_ranks: Vec<u32>,
    },
    #[error("engine-core output dispatcher closed: {message}")]
    DispatcherClosed { message: String },
    #[error("engine-core client is closed: {message}")]
    ClientClosed { message: String },
    #[error("request output stream for `{request_id}` closed unexpectedly")]
    RequestStreamClosed { request_id: String },
    #[error("utility call `{method}` failed (call_id={call_id}): {message}")]
    UtilityCallFailed {
        method: String,
        call_id: UtilityCallId,
        message: String,
    },
    #[error("utility call `{method}` returned an invalid result (call_id={call_id}): {message}")]
    UtilityResultDecode {
        method: String,
        call_id: UtilityCallId,
        message: String,
    },
    #[error("utility call `{method}` closed unexpectedly (call_id={call_id})")]
    UtilityCallClosed { method: String, call_id: u64 },
    #[error("utility call `{method}` returned inconsistent results across engines: {values}")]
    InconsistentUtilityResults { method: String, values: String },

    /// A special variant to allow cloning the same error.
    #[error(transparent)]
    Shared(Arc<Self>),
}

View on GitHub (pinned to c794754062)

Solutions

  1. Rebuild/reinstall both frontend and engine-core from the same vLLM version so codecs match
  2. If you added a custom utility method, verify the result type's serialization is identical on both sides
  3. Check call_id in logs to correlate which utility and payload failed decoding
Defensive patterns

Strategy: fallback

Type guard

pub fn is_utility_result_decode(e: &vllm_engine_core_client::Error) -> bool {
    matches!(e, vllm_engine_core_client::Error::UtilityResultDecode { .. })
}

Try / catch

match client.utility_call(method, payload).await {
    Err(e @ vllm_engine_core_client::Error::UtilityResultDecode { method, .. }) => {
        tracing::error!("codec mismatch on {method}: {e}");
        Err(e.into()) // not retryable until versions are aligned
    }
    other => other,
}

Prevention

When it happens

Trigger: The engine-core serializes the utility result with a different schema/protobuf/messagepack version than the client expects; enum variant or field renames across versions; truncated or corrupt frames on the IPC channel.

Common situations: Mixing an old frontend binary with a newer engine-core (or vice versa) after a release changed utility result types; hand-rolled utility methods whose codec drift; flaky IPC producing corrupt frames.

Related errors


AI-assisted analysis of vllm-project/vllm@c794754062 (2026-08-14). Data as JSON: /api/errors/2fda151d35e33bdc. Report an issue: GitHub.