[CI] Fix mypy for vllm/v1/core and vllm/v1/engine

[yewentao256]

Purpose

Part of #26533

FIx mypy for vllm/v1/core and vllm/v1/engine

@hmellor CC

Test

pre-commit run --hook-stage manual mypy-3.10 -a
Found 31 errors in 9 files (checked 249 source files)

pre-commit run --hook-stage manual mypy-3.10 -a
Run mypy for Python 3.10.................................................Passed

[gemini-code-assist]

Code Review

This pull request introduces fixes to address mypy errors in vllm/v1/core and vllm/v1/engine. The changes primarily involve adding type hints, explicit casts, and safer attribute access patterns to improve type safety and satisfy mypy checks.

I've found one critical issue in vllm/v1/engine/llm_engine.py where the new logic for processing request outputs can lead to data loss by incorrectly filtering a list of mixed-type results. I've provided a detailed comment and a suggested fix for this issue.

Other changes appear correct and effectively address the mypy errors.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR.

• @codex fix this CI failure
• @codex address that feedback

[yewentao256]

@hmellor CC

[hmellor]

Why does the type need to be ignored here? Should this not always return a bool?

[yewentao256]

The issue is vllm/v1/engine/async_llm.py:661: error: Item "None" of "ObservabilityConfig | None" has no attribute "otlp_traces_endpoint" [union-attr]

    async def is_tracing_enabled(self) -> bool:
        assert self.observability_config is not None
        return self.observability_config.otlp_traces_endpoint is not None

I think this is not very elegant so just #type ignore

[hmellor]

This should probably error if we if the model executor doesn't have this method

[yewentao256]

Just to confirm, you meant we should raise an error here in case the model executor doesn't have this method?

[mergify]

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

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

[yewentao256]

Hi @hmellor, wondering is there anything else we should update?

[DarkLight1337]

This PR is failing pre-commit on main

[NickLucche]

@DarkLight1337 this wasn't force-merged right? Can we still break pre-commit with a clean-merge..?

[DarkLight1337]

It wasn't. But this PR was behind main when it was merged.

[njhill]

😢

[yewentao256]

@DarkLight1337 Is there any way we can avoid this? A clean merge shouldn't cause trouble to CI

[hmellor]

It happens when a PR changes a pre-commit rule.

1. PR1 makes a change to a pre-commit rule (like this PR with mypy) and CI starts
2. PR2 makes a change that would fail this new rule but the CI starts in parallel without the new rule applied
3. Both PRs merge cleanly and now pre-commit fails on main

The best way to prevent this is to always merge from main before attempting to merge a PR which changes pre-commit rules.