[Misc] Use VLLMValidationError for user-facing errors in Responses harmony#37327
[Misc] Use VLLMValidationError for user-facing errors in Responses harmony#37327umut-polat wants to merge 1 commit intovllm-project:mainfrom
Conversation
umut-polat
requested review from
DarkLight1337,
aarnphm,
chaunceyjiang and
russellb
as code owners
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request replaces ValueError with VLLMValidationError for user-input validation errors in the Responses API Harmony conversion layer, adding a parameter field to error responses to help API clients identify invalid request parts. The changes involve modifying the _parse_chat_format_message and response_input_to_harmony functions to raise VLLMValidationError with specific parameter names when encountering invalid input, enhancing error reporting for API clients.
| """Parse an OpenAI chat-format dict into Harmony messages.""" | ||
| role = chat_msg.get("role") | ||
| if role is None: | ||
| raise ValueError(f"Message has no 'role' key: {chat_msg}") |
There was a problem hiding this comment.
This ValueError should be replaced with VLLMValidationError to provide more context about the error, as the pull request description indicates. The parameter field should be set to "messages" to indicate that the error is related to the messages input.
raise VLLMValidationError(
f"Message has no 'role' key: {chat_msg}",
parameter="messages",
)| call_response = prev_response | ||
| break | ||
| if call_response is None: | ||
| raise ValueError(f"No call message found for {call_id}") |
There was a problem hiding this comment.
This ValueError should be replaced with VLLMValidationError to provide more context about the error, as the pull request description indicates. The parameter field should be set to "input" to indicate that the error is related to the input parameter.
raise VLLMValidationError(
f"No call message found for {call_id}",
parameter="input",
)| msg = msg.with_recipient(f"functions.{response_msg['name']}") | ||
| msg = msg.with_content_type("json") | ||
| else: | ||
| raise ValueError(f"Unknown input type: {response_msg['type']}") |
There was a problem hiding this comment.
This ValueError should be replaced with VLLMValidationError to provide more context about the error, as the pull request description indicates. The parameter field should be set to "input" to indicate that the error is related to the input parameter.
raise VLLMValidationError(
f"Unknown input type: {response_msg['type']}",
parameter="input",
)
…rmony Replace ValueError with VLLMValidationError for three user-input validation errors in the Responses API Harmony conversion layer: - Missing 'role' key in chat-format message (parameter: messages) - Invalid call_id reference in function_call_output (parameter: input) - Unknown input type in previous response (parameter: input) These errors are triggered by malformed user input. Using VLLMValidationError provides the parameter field in the error response, helping API clients identify which part of their request is invalid. Internal processing errors (browser message parsing, unknown channel) are kept as ValueError since they indicate server-side issues rather than invalid user input. Signed-off-by: umut-polat <52835619+umut-polat@users.noreply.github.com>
umut-polat
force-pushed
the
fix/responses-harmony-validation
branch
from
f647c43 to
1d03fc6
Compare
1 participant
Summary
Replace
ValueErrorwithVLLMValidationErrorfor three user-input validation errors in the Responses API Harmony conversion layer. This adds theparameterfield to error responses, helping API clients identify which part of their request is invalid.Changed
rolekey in chat-format message →parameter: "messages"call_idreference infunction_call_output→parameter: "input"parameter: "input"Not changed
Internal processing errors (browser message parsing, unknown channel) are kept as
ValueErrorsince they indicate server-side issues rather than invalid user input.This continues the effort from #36256, #35531, #35510 to use
VLLMValidationErrorconsistently across the frontend layer.