[KrxGu]

Fixes #42489

When a resumable request receives a streaming_update, the scheduler
rebuilds the prompt by folding in already-computed output tokens plus
the new chunk. That renewed prompt can exceed max_model_len even though
the original request was fine, and when it did, gpu_input_batch.add_request()
would crash with an opaque NumPy broadcast error:

ValueError: could not broadcast input array from shape (279,) into shape (256,)

The fix adds a length check at the start of _update_request_as_session()
before any state is mutated. If renewed_prompt_len >= max_model_len, the
method returns early and the caller finishes the request with
FINISHED_LENGTH_CAPPED (same as any other length-exceeded request).
Both call sites are covered: _handle_stopped_request() and add_request().
A defensive bounds check is also added in GPUInputBatch.add_request() so
any future regression produces a clear error instead of a NumPy traceback.

Testing: 4 CPU-only scheduler unit tests covering the overflow path,
exact boundary, and both call sites. No model or GPU required.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[gemini-code-assist]

Code Review

This pull request implements a guard against max_model_len overflow for resumable streaming updates. It modifies the scheduler to check if a renewed prompt length will exceed the maximum allowed length before applying updates, ensuring requests are finished with a FINISHED_LENGTH_CAPPED status when necessary. Additionally, defensive checks were added to the GPU input batch processing to catch potential regressions, and comprehensive unit tests were included to verify the new logic. I have no feedback to provide.

[KrxGu]

This PR is ready for review.

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @KrxGu.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[nvbfalk]

Thanks for putting this up. This is exactly where we ended up too (RFC #51948). The one thing we'd ask to be softer is
the outcome: rather than FINISHED_LENGTH_CAPPED, end the reply and leave the session
resumable (or make that opt-in). #53876 builds bounded sessions on top of exactly
that distinction.

[sawsa307]

Thank you @KrxGu for the PR! A few things before this can land:

1. Rebase: the PR conflicts with current main, and the tests reference skipped_waiting, which #58947 removed (now kv_holding_waiting/deferred_waiting). The tests would also fit better in tests/v1/streaming_input/test_scheduler_streaming.py alongside the sibling coverage there.
2. V2 runner: the defensive bounds check in gpu_input_batch.add_request covers MRV1 only. MRV2 has the same fixed-width [max_num_reqs, max_model_len] buffer with an unguarded write in vllm/v1/worker/gpu/states.py (all_token_ids.stage_write in add_request). The scheduler-side guard covers V2, so this is belt-and-braces — but either add the V2 counterpart or note it in the PR body.
3. Encoder-token growth: the prompt-length check misses pure encoder-token accumulation (the audio/realtime case from #39996 that #40072 covered). Could you fold the encoder-token accounting into the same pre-mutation check and add ianliuy as co-author?