Skip to content

[bugfix] ascend schedule encountered an incorrect req block length in… #2429

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

liziyu179
Copy link
Contributor

@liziyu179 liziyu179 commented Aug 19, 2025

… the check_watermark_for_prefill function

What this PR does / why we need it?

Does this PR introduce any user-facing change?

How was this patch tested?

… the check_watermark_for_prefill function

Signed-off-by: liziyu <[email protected]>
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This PR fixes a bug in the watermark check by using the correct block length. The fix is correct in principle, but the implementation is not robust and can lead to crashes for new requests. I've added a critical comment with a suggested improvement to prevent potential KeyError and IndexError exceptions.

Comment on lines 418 to 421
req_blocks = self.kv_cache_manager.coordinator.get_blocks(
request.request_id)
num_new_blocks = (num_required_blocks - len(req_blocks) -
num_new_blocks = (num_required_blocks - len(req_blocks[0]) -
len(computed_blocks))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

The change from len(req_blocks) to len(req_blocks[0]) is conceptually correct for getting the number of allocated blocks. However, the current implementation is not robust and can lead to runtime errors:

  1. self.kv_cache_manager.coordinator.get_blocks(request.request_id) will raise a KeyError if a request has no blocks allocated yet, which is the case for new requests from the waiting queue.
  2. If get_blocks were to return an empty list for a new request, req_blocks[0] would then raise an IndexError.

This can cause the scheduler to crash. The implementation should be updated to handle these cases gracefully.

        req_blocks = self.kv_cache_manager.coordinator.req_to_blocks.get(
            request.request_id, [])
        num_allocated_blocks = len(req_blocks[0]) if req_blocks else 0
        num_new_blocks = (num_required_blocks - num_allocated_blocks -
                          len(computed_blocks))

Copy link

👋 Hi! Thank you for contributing to the vLLM Ascend project. The following points will speed up your PR merge:‌‌

  • A PR should do only one thing, smaller PRs enable faster reviews.
  • Every PR should include unit tests and end-to-end tests ‌to ensure it works and is not broken by other future PRs.
  • Write the commit message by fulfilling the PR description to help reviewer and future developers understand.

If CI fails, you can run linting and testing checks locally according Contributing and Testing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant