fix error response format to match OpenAI API standard#1259
fix error response format to match OpenAI API standard#1259
Conversation
Wrap error responses in {"error": {"message", "type", "param", "code"}}
envelope to align with vLLM and OpenAI SDK expectations.
![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 updates the create_error_response function in both api_http.py and api_openai.py to return a structured error object containing a message, type, parameter, and status code. The feedback recommends converting the code field from an integer to a string to ensure compatibility with the OpenAI API specification. Additionally, it is suggested to centralize the duplicated error response logic into a shared utility module to reduce maintenance overhead and prevent logic divergence.
| g_objs.metric_client.counter_inc("lightllm_request_failure") | ||
| return JSONResponse({"message": message}, status_code=status_code.value) | ||
| return JSONResponse( | ||
| {"error": {"message": message, "type": err_type, "param": param, "code": status_code.value}}, |
There was a problem hiding this comment.
The OpenAI API specification typically expects the code field to be a string or null. Using an integer might cause issues with some client libraries that strictly validate types. Converting the status code to a string is a safer approach and matches the behavior of other OpenAI-compatible servers like vLLM.
| {"error": {"message": message, "type": err_type, "param": param, "code": status_code.value}}, | |
| {"error": {"message": message, "type": err_type, "param": param, "code": str(status_code.value)}}, |
| def create_error_response( | ||
| status_code: HTTPStatus, message: str, err_type: str = None, param: str = None | ||
| ) -> JSONResponse: |
There was a problem hiding this comment.
This function is a duplicate of the one implemented in api_http.py. Duplicating logic across files increases maintenance overhead and the risk of divergence. It is recommended to centralize this utility in a shared module. If circular dependencies between api_http.py and api_openai.py are a concern, consider moving the shared logic to a common utility file (e.g., lightllm/utils/api_utils.py) that both can import.
| g_objs.metric_client.counter_inc("lightllm_request_failure") | ||
| return JSONResponse({"message": message}, status_code=status_code.value) | ||
| return JSONResponse( | ||
| {"error": {"message": message, "type": err_type, "param": param, "code": status_code.value}}, |
There was a problem hiding this comment.
The code field should be a string to align with the OpenAI API standard, ensuring consistency with the implementation in api_http.py.
| {"error": {"message": message, "type": err_type, "param": param, "code": status_code.value}}, | |
| {"error": {"message": message, "type": err_type, "param": param, "code": str(status_code.value)}}, |
1 participant
Summary
{"error": {"message", "type", "param", "code"}}envelope to align with vLLM and OpenAI SDK expectationscreate_error_responsefunctions inapi_http.pyandapi_openai.pyBadRequestError, 404 →NotFoundError, 5xx →InternalServerErrorBackground
The OpenAI Python SDK and most compatible clients parse
response["error"]["message"]to extract error details. LightLLM's previous flat{"message": "..."}format causedKeyErrorexceptions in client error-handling code.Test plan
/v1/chat/completionswith invalid parameters return the nested{"error": {...}}format/v1/completionsreturn the same formatKeyErrorapi_http.pyalso return the correct format