129: Refactoring decorators by JaeYeonLee0621 · Pull Request #188 · TU-Wien-dataLAB/aqueduct

JaeYeonLee0621 · 2026-09-11T13:12:52Z

1. Decorators refactored

Split the large gateway/views/decorators.py into a new gateway/decorators/ package with one module per concern:

auth.py — token_authenticated, tos_accepted, check_limits
body.py — parse_body, FileSizeError, ensure_usage, resolve_alias
availability.py — check_model_availability
log.py — log_request
errors.py — catch_router_exceptions
mcp.py — check_mcp_server_availability, mcp_transport_security, parse_jsonrpc_message
responses.py — validate_response_id, check_tool_availability and helpers
files.py — require_files_api_client, process_batch_file and its helpers
chat_completions.py — process_file_content, normalize_reasoning_fields and their helpers
types.py — shared type aliases
init.py — re-exports the decorators as a single facade

The old gateway/views/decorators.py was deleted.

2. Review opinions applied

check_mcp_server_availability moved into mcp.py.
get_relay_model_name removed (it was unused).
process_file_content and normalize_reasoning_fields grouped in chat_completions.py.
Utility functions placed next to the decorators that use them, rather than in a separate utils module.

meffmadd · 2026-09-16T14:04:57Z

+)
+from gateway.decorators.responses import check_tool_availability, validate_response_id
+
+__all__ = [


Should we use __all__ here? I guess we just assume we want to export everything and we still have private functions with _. This is always more work with little gain.

Agreed, __all__ isn't needed here, so I've removed it. External code can import the decorators using their full path.

We also use it in the model refactor so you can also leave it... sorry that was probably a bit premature.

meffmadd · 2026-09-16T14:11:31Z

+    return wrapper
+
+
+def check_limits(view_func: AsyncView) -> AsyncView:


I think check_limits should not belong to auth. As we already have plans to expand how we handle limits, this should get its own file I think.

I put the check_limits definition in a new limits.py file. I'm open to suggestions on the file name or placement :)

meffmadd · 2026-09-16T14:14:46Z

+    return False
+
+
+def normalize_reasoning_fields(view_func: AsyncView) -> AsyncView:


Tangential but do we really only need to normalize reasoning fields for chat completions and not responses? I forgot but maybe the Responses was unified from the beginning anyways.

I'm not sure I fully follow this comment. Could you explain it a bit more?

There were inconsistencies with the different Chat Completions API implementations where some used reasoning and others reasoning_content so we just make sure both are in the response. I was wondering if the Responses API has the same issue.

I'm not familiar with this part, but from what AI said, the Responses API path doesn't go through LiteLLM's routing. It calls client.responses.create() directly on an OpenAI-compatible SDK, and the result comes back as a canonical, strongly typed Response pydantic model. So It said, It doesn't have the same issue as the Chat Completions API.

meffmadd · 2026-09-16T14:30:01Z

I do not really like the name of the file. Should we have a types.py file? Or leave it in utils.py? Basically can you check how many custom utility classes and functions we have/expect to have and split accordingly?

I renamed the file to response_type.py, since putting all these classes in a utils.py file didn't feel right and types.py seemed too generic. Let me know if you'd prefer something else and I'll change it.

Yes ok that makes sense! Also note that this file heavily depends on 152-http-requests-processing and I wanted to check if we could rewrite the classes so that we can get rid of the middleware introduced there. So we might have to merge this first otherwise we have to merge again here etc.

meffmadd · 2026-09-16T14:31:10Z

+    return status_map.get(status, "invalid_request_error")
+
+
+def in_wildcard(value: str | None, allowed_values: list[str]) -> bool:


This is probably a util function right?

I moved this function to utils.py.

meffmadd · 2026-09-16T14:31:52Z

+    return valid
+
+
+def register_response_in_cache(response_id: str | None, model: str, email: str) -> None:


This and the following functions are specific to the Responses API and not related to Django HTTP responses at all so these should be moved.

I moved the cache-related definitions into response_cache.py.

I think they should be in views/responses.py since it is so specific to the Responses endpoint. But I am not sure.

I tried making this change, but it runs into two circular imports.

Before

responses_cache.py (register/get/delete) → decorators/responses.py (validate_response_id) responses_cache.py (register/get/delete) → views/responses.py (create_response) responses_cache.py (register/get/delete) → views/utils.py (ResponseRegistrationWrapper)

After (functions moved to views/responses.py):

decorators/responses.py (validate_response_id) <-> views/responses.py (get_response_from_cache) views/utils.py(ResponseRegistrationWrapper) <-> views/responses.py (register_response_in_cache)

fix: pre-commit

ae2d55f

JaeYeonLee0621 self-assigned this Sep 11, 2026

fix: import paty

7332e3c

JaeYeonLee0621 requested review from meffmadd and natkam September 14, 2026 10:21

JaeYeonLee0621 marked this pull request as ready for review September 14, 2026 10:24

meffmadd added this pull request to stack #190 September 15, 2026 07:20

meffmadd requested changes Sep 16, 2026

View reviewed changes

apply reviews

c119433

JaeYeonLee0621 requested a review from meffmadd September 17, 2026 12:55

Jaeyeon Lee added 2 commits September 17, 2026 15:55

cleanup __init__ file and change relative path to full path

ebda1ae

reset __init__

77a9b9f

		return wrapper


		def check_limits(view_func: AsyncView) -> AsyncView:

		return False


		def normalize_reasoning_fields(view_func: AsyncView) -> AsyncView:

		return status_map.get(status, "invalid_request_error")


		def in_wildcard(value: str \| None, allowed_values: list[str]) -> bool:

		return valid


		def register_response_in_cache(response_id: str \| None, model: str, email: str) -> None:

Conversation

JaeYeonLee0621 commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

1. Decorators refactored

2. Review opinions applied

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JaeYeonLee0621 Sep 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JaeYeonLee0621 Sep 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JaeYeonLee0621 Sep 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

JaeYeonLee0621 commented Sep 11, 2026 •

edited

Loading

JaeYeonLee0621 Sep 17, 2026 •

edited

Loading

JaeYeonLee0621 Sep 21, 2026 •

edited

Loading

JaeYeonLee0621 Sep 21, 2026 •

edited

Loading