vllm-project/vllm · error · ValueError

Unsupported new_block_ids type {type(new_block_ids)}: should

Error message

Unsupported new_block_ids type {type(new_block_ids)}: should be None[list[int], ...], tuple or list[int].

What it means

ValueError raised in LMCache's VLLM v1 adapter request-tracker update when new_block_ids arrives in a type other than None, tuple, or list (the three shapes the scheduler is known to emit). The adapter normalizes each shape (None -> [], tuple -> first element, list kept) and this error fires only for genuinely unexpected types, meaning scheduler/adapter version drift or a corrupted metadata object. It protects allocated_block_ids from being extended with garbage.

Source

Thrown at vllm/distributed/kv_transfer/kv_connector/v1/lmcache_integration/vllm_v1_adapter.py:236

    ) -> None:
        """Update the request tracker when a running request is
        scheduled again
        """

        self.token_ids.extend(new_token_ids)

        if new_block_ids is None:
            # https://github.com/vllm-project/vllm/commit/
            # b029de9902aa3ac58806c8c17776c7074175b6db
            new_block_ids = []
        elif len(new_block_ids) == 0:
            new_block_ids = []
        elif isinstance(new_block_ids, tuple):
            new_block_ids = new_block_ids[0]
        elif isinstance(new_block_ids, list):
            pass
        else:
            raise ValueError(
                f"Unsupported new_block_ids type {type(new_block_ids)}: "
                f"should be None[list[int], ...], tuple or list[int]."
            )
        self.allocated_block_ids.extend(new_block_ids)

        # When a request is scheduled again, and the number of new tokens
        # is 1 (excluding chunked prefill), the request is in decode phase.
        if len(new_token_ids) == 1:
            self.is_decode_phase = True


@dataclass
class ReqMeta:
    # Request id
    req_id: str
    # Request tokens
    token_ids: list[int]  # torch.Tensor
    # Slot mapping

View on GitHub (pinned to c794754062)

Solutions

1. Pin lmcache and vllm to a known-compatible version pair (check the LMCache release notes for the supported vLLM version).
2. If you control the caller, ensure new_block_ids is None, a tuple of per-slide lists, or a flat list[int].
3. Log type(new_block_ids) and its repr before the call to confirm what the scheduler actually sent.

def is_supported_block_ids(v) -> bool:
    return v is None or isinstance(v, (tuple, list))

Catch ValueError at the adapter boundary and log type(new_block_ids) — this is version drift; fix by pinning compatible vllm/lmcache versions rather than catching at runtime.

When it happens

Trigger: Scheduler sends new_block_ids as a dict, generator, ndarray, or custom object after a vLLM internal API change; downstream code mutates scheduler_output.new_block_ids[i] into an unexpected container; running an LMCache integration built against a different vLLM scheduler contract.

Common situations: Version mismatch between the lmcache package and vLLM's scheduler output format; monkey-patching or custom schedulers that emit non-standard block id containers.

Related errors

• Request {req_id} is not in _unfinished_requests, but it is s
• Unknown KVConnectorRole: {self.role}
• Either vllm_config must be provided, or all of model_config,
• MLA only works with naive serde mode..
• layerwise MLA connector is not supported yet

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