vllm-project/vllm · error · ValueError

Request {req_id} is not in _unfinished_requests, but it is s

Error message

Request {req_id} is not in _unfinished_requests, but it is scheduled to be cached

What it means

ValueError raised while processing scheduler output in the LMCache v1 adapter: a request appears in cached_reqs.req_ids (scheduled for KV caching) but is absent from the adapter's _unfinished_requests map. The map is populated when requests finish and removed as they complete, so this means the adapter's view of live requests has diverged from the scheduler's — typically a finished/aborted request being scheduled again, or an engine-internal lifecycle bug. It aborts the update loop to prevent caching tokens for an unknown request.

Source

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

                    self._block_size,
                    self._lmcache_chunk_size,
                    load_spec=None,
                    discard_partial_chunks=self._discard_partial_chunks,
                )
                if req_meta is not None:
                    meta.add_request(req_meta)
            return meta

        for i, req_id in enumerate(cached_reqs.req_ids):
            request_tracker = self._request_trackers[req_id]
            num_new_tokens = scheduler_output.num_scheduled_tokens[req_id]
            if cached_request := self._unfinished_requests.get(req_id):
                num_current_tokens = len(request_tracker.token_ids)
                new_token_ids = cached_request.all_token_ids[
                    num_current_tokens : num_current_tokens + num_new_tokens
                ]
            else:
                raise ValueError(
                    f"Request {req_id} is not in _unfinished_requests, "
                    f"but it is scheduled to be cached"
                )
            new_block_ids = cached_reqs.new_block_ids[i]

            request_tracker.update(new_token_ids, new_block_ids)

            req_meta = ReqMeta.from_request_tracker(
                request_tracker,
                self._block_size,
                self._lmcache_chunk_size,
                load_spec=None,
                discard_partial_chunks=self._discard_partial_chunks,
                save_decode_cache=self._save_decode_cache,
            )
            if req_meta is not None:
                meta.add_request(req_meta)

View on GitHub (pinned to c794754062)

Solutions

1. Align lmcache and vllm versions to a tested compatible pair (check LMCache's compatibility matrix).
2. Check engine logs for aborted/preempted requests immediately preceding the error to identify the racing request.
3. Reproduce with preemptions/aborts disabled or reduced to see if request lifecycle churn is the trigger, and report with a minimal repro to LMCache/vLLM.
4. As a workaround for a stuck deployment, restart the engine; the inconsistency is in-memory only.

Catch ValueError around the scheduler-output processing loop, log req_id plus the adapter's _unfinished_requests keys for the diff, and fail loudly — this indicates state divergence that should be reported, not papered over.

When it happens

Trigger: A request that was aborted or completed is still present in the scheduler's cached_reqs batch; request eviction in the adapter racing with a reschedule; version drift between the adapter's tracking logic and the scheduler's request lifecycle.

Common situations: Running an lmcache version not matched to the deployed vLLM scheduler behavior; crashes under heavy preemption/abort workloads; custom schedulers altering request finish ordering.

Related errors

• Unsupported new_block_ids type {type(new_block_ids)}: should
• 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
• LMCacheMPConnector only works without hybrid kv cache manage

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