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
- Rebuild/reinstall both frontend and engine-core from the same vLLM version so codecs match
- If you added a custom utility method, verify the result type's serialization is identical on both sides
- 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
- Deploy frontend and engine-core from the same release artifact
- Pin the vLLM version in both processes; never mix minor versions across an IPC boundary
- For custom utilities, add round-trip encode/decode tests shared by both sides
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
- messagepack encode failed for {target_type}: {message}
- messagepack decode failed for {target_type}: {message}
- messagepack ext value decode failed: {message}
- unexpected startup handshake message: {message}
- unexpected output on main dispatcher path: {message}
AI-assisted analysis of vllm-project/vllm@c794754062 (2026-08-14).
Data as JSON: /api/errors/2fda151d35e33bdc.
Report an issue: GitHub.