[gpt-oss][Bugfix] Fix gpt-oss toolcall

[clearhanhui]

Purpose

vLLM server breaks down when calls gpt-oss builtin tools.

ValueError: operands could not be broadcast together with shape (1,) (2,)

Related issues: 23196 23108.

The reason is that, add_request receives a request with an existing req_id, and it is append again into _req_ids list.
Then it raises the above error while calling _prepare_inputs:

Test Plan

Test Result

(Optional) Documentation Update

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors.

You ask your reviewers to trigger select CI tests on top of fastcheck CI.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can either: Add ready label to the PR or enable auto-merge.

If you have any questions, please reach out to us on Slack at https://slack.vllm.ai.

🚀

[gemini-code-assist]

Code Review

This pull request aims to fix a bug where the vLLM server crashes when handling GPT-OSS tool calls due to requests with existing IDs being re-added. The proposed change correctly identifies and uses the index of an existing request. However, this fix introduces a new issue related to the state management of logits processors for non-pooling models, which could lead to incorrect generation behavior. I've added a critical comment with a detailed explanation and a suggested alternative implementation to address both issues correctly.

[gemini-code-assist]

While this change correctly prevents duplicate request entries, it introduces an issue for non-pooling models by creating an inconsistent state for logits processors.

The _register_add_request function is called for non-pooling models before this check. It adds an entry to self.batch_update_builder.added with a newly allocated req_index. Your change then overwrites req_index with the existing request's index, but the batch_update_builder is left with a stale entry pointing to the wrong index. This can lead to incorrect behavior during logits processing.

A safer approach is to check for req_id's existence before calling _register_add_request. This ensures a request is only registered as "added" when it is truly new.

Consider this alternative structure to replace lines 283-291:

        req_id = request.req_id
        if req_id in self.req_id_to_index:
            req_index = self.req_id_to_index[req_id]
        elif not self.is_pooling_model:
            # New request index bookkeeping for autoregressive models.
            req_index = self._register_add_request(request)
        else:
            req_index = self.num_reqs

[heheda12345]

Nice catch!

But there maybe other places that assume different requests have different request ids. For a safer fix, what about changing OpenAIServing._generate_with_builtin_tools?

Basically, you can change the request_id of different rounds to different numbers here

vllm/vllm/entrypoints/openai/serving_engine.py

Line 976 in da65bec

request_id,

and recover the res.request_id before here:

vllm/vllm/entrypoints/openai/serving_engine.py

Line 982 in da65bec

context.append_output(res)

[heheda12345]

@clearhanhui Hi, can you help to update this PR?

[clearhanhui]

@clearhanhui Hi, can you help to update this PR?

@heheda12345
Sorry for my late reply, I may have no free time woking on this. Close this PR and re-open another one, if you like.

For the OpenAI's response API, adding a number suffix after request_id, indicating the "number of current turn", may solve the problem. But changing request_id is not a prefer choice for me, since I also have modified request_id related code for other needs and it should be same.

[heheda12345]

@clearhanhui Thanks. I'm trying to fix this but I can't reproduce it. Can you tell me how to reproduce?

[clearhanhui]

@clearhanhui Thanks. I'm trying to fix this but I can't reproduce it. Can you tell me how to reproduce?

Just following the recipe below, and I found the bug when I was trying to reproduce the performace of gpt-oss-20b on AIME25 with python-tool.
https://docs.vllm.ai/projects/recipes/en/latest/OpenAI/GPT-OSS.html#tool-use

[heheda12345]

Based on #23108 (comment), I think this problem has been fixed on main branch. Thanks for exploring this!