[openapi server] log exception in exception handler(2/N)

[andyxning]

Purpose

This is a follow-up PR for #31164

1. Refactor models related exception handle just like other openapi
2. Refactor create_error_response to the vllm.entrypoints.utils.create_error_response.
3. Refactor all the handler is None openapi response status code from BadRequestError to NotImplementedError.

Test Plan

NA

Test Result

NA

---

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.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

[gemini-code-assist]

Code Review

This pull request refactors exception handling by centralizing it in vllm/entrypoints/utils.py, which is a positive step towards better maintainability. My feedback focuses on improving the robustness of this new centralized logic. The current implementation relies on string matching on exception messages, which is fragile. I've suggested using custom exception types instead, which would make the error handling more explicit and resilient. I also pointed out an instance where overly broad exception catching could lead to mis-classifying server-side errors as client errors, and recommended more granular handling.

[gemini-code-assist]

Catching a broad Exception and re-raising it to be classified as a BadRequestError can be problematic. This try block covers operations like downloading from a URL, which can fail for various reasons (e.g., network issues, server-side problems with the URL host) that are not client errors. Classifying all such failures as a 400 Bad Request can be misleading and hide the true cause of the error. It would be better to have more granular exception handling to differentiate between client errors (like an invalid URL) and server-side or transient errors, and map them to appropriate HTTP status codes (e.g., 4xx vs 5xx).

[gemini-code-assist]

Using string matching on exception messages to determine error types is brittle and can lead to incorrect error classification. If the underlying error messages change, this logic will break. A more robust approach is to use custom exception types.

For example:

1. For the 'No adapter found' case, a specific LoRAAdapterNotFoundError could be raised from the LoRA loading logic.
2. For transcription/translation failures, a custom AudioProcessingError could be raised from run_batch.py.

Then, you could check for these specific exception types here:

# from vllm.lora.exception import LoRAAdapterNotFoundError
# from vllm.entrypoints.openai.run_batch import AudioProcessingError

# ...

elif isinstance(exc, LoRAAdapterNotFoundError):
    err_type = "NotFoundError"
    status_code = HTTPStatus.NOT_FOUND
    param = None
elif isinstance(exc, AudioProcessingError):
    err_type = "BadRequestError"
    status_code = HTTPStatus.BAD_REQUEST
    param = None

This would make the error handling more explicit, maintainable, and resilient to changes.

[andyxning]

Will do.

[noooop]

Can create_error_response here be replaced with NotImplementedError? If yes, please do it.

vllm/vllm/entrypoints/pooling/classify/api_router.py

Lines 32 to 39 in c012a8c

	if handler is None:
	error_response = create_error_response(
	message="The model does not support Classification API"
	)
	return JSONResponse(
	content=error_response.model_dump(),
	status_code=error_response.error.code,
	)

[andyxning]

Normal Exception has changed from BadRequestError to InternalServerError, i.e., http response status code from 404 to 500

[andyxning]

For example, if --enable-lora arg is not set, exception occurred during load lora adapter will be:

{"error":{"message":"Call to add_lora method failed: LoRA is not enabled. Use --enable-lora to enable LoRA.","type":"InternalServerError","param":null,"code":500}}

[noooop]

I now think it's better to put exceptions in vllm/exceptions.py rather than keeping them separate.

[andyxning]

This code has been deleted.

[andyxning]

Can create_error_response here be replaced with NotImplementedError? If yes, please do it.

vllm/vllm/entrypoints/pooling/classify/api_router.py

Lines 32 to 39 in c012a8c

	if handler is None:
	error_response = create_error_response(
	message="The model does not support Classification API"
	)
	return JSONResponse(
	content=error_response.model_dump(),
	status_code=error_response.error.code,
	)

@noooop I have refactored all the occurances about handler is None in the api from message to NotImplementedError exception. Thus, the response will be refactored from

{
    "error": {
        "message": "The model does not support Chat Completions API",
        "type": "BadRequestError",
        "param": null,
        "code": 400
    }
}

to

{
    "error": {
        "message": "The model does not support Chat Completions API",
        "type": "NotImplementedError",
        "param": null,
        "code": 501
    }
}

[noooop]

Can create_error_response here be replaced with NotImplementedError? If yes, please do it.

vllm/vllm/entrypoints/pooling/classify/api_router.py

Lines 32 to 39 in c012a8c

	if handler is None:
	error_response = create_error_response(
	message="The model does not support Classification API"
	)
	return JSONResponse(
	content=error_response.model_dump(),
	status_code=error_response.error.code,
	)

@noooop I have refactored all the occurances about handler is None in the api from message to NotImplementedError exception. Thus, the response will be refactored from

{
    "error": {
        "message": "The model does not support Chat Completions API",
        "type": "BadRequestError",
        "param": null,
        "code": 400
    }
}

to

{
    "error": {
        "message": "The model does not support Chat Completions API",
        "type": "NotImplementedError",
        "param": null,
        "code": 501
    }
}

I think at least for pooling entrypoints, this change is acceptable. Because now the corresponding pooling entrypoints will only be mounted on entrypoints that support pooling tasks, I think this exception will hardly ever be triggered.

vllm/vllm/entrypoints/pooling/__init__.py

Lines 21 to 47 in bd2659a

	def register_pooling_api_routers(
	app: FastAPI, supported_tasks: tuple["SupportedTask", ...]
	):
	from vllm.entrypoints.pooling.pooling.api_router import router as pooling_router
	app.include_router(pooling_router)
	if "classify" in supported_tasks:
	from vllm.entrypoints.pooling.classify.api_router import (
	router as classify_router,
	)
	app.include_router(classify_router)
	if "embed" in supported_tasks:
	from vllm.entrypoints.pooling.embed.api_router import router as embed_router
	app.include_router(embed_router)
	# Score/rerank endpoints are available for:
	# - "score" task (cross-encoder models)
	# - "embed" task (bi-encoder models)
	# - "token_embed" task (late interaction models like ColBERT)
	if any(t in supported_tasks for t in ("score", "embed", "token_embed")):
	from vllm.entrypoints.pooling.score.api_router import router as score_router
	app.include_router(score_router)

[mergify]

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

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

[andyxning]

/cc @DarkLight1337 @noooop

[andyxning]

@DarkLight1337 Seems the ci has nothing to do with this PR. can you help force merge this PR.