Bug: data kwarg in dependency results in an exception

[declaresub]

Description

The litestar documentation suggests that one can use the reserved 'data' kwarg in a dependency function. My attempt to do so results in an exception, traceback included below.

MCVE

from typing import Annotated

from litestar import Litestar, post
from litestar.di import Provide
from litestar.params import Dependency
from litestar.plugins.pydantic import PydanticInitPlugin
from pydantic import BaseModel


class Hello(BaseModel):
    hello: str


async def post_hello_world_dep(data: Hello):
    return Hello(hello=data.hello)


@post("/", dependencies={"resp": Provide(post_hello_world_dep)})
async def post_hello_world(resp: Annotated[Hello, Dependency()]) -> Hello:
    return resp


pydantic_plugin = PydanticInitPlugin(prefer_alias=True, exclude_unset=True)

app = Litestar(
    route_handlers=[post_hello_world],
    plugins=[pydantic_plugin],
)

Steps to reproduce

Create a virtual environment (I used python 3.10.6, but problem also happens with 3.13.5).
Install pydantic, litestar.
Save the MCVE code to a file named 'data_example.py' in the virtual environment.
python -m data_example.py

Traceback (most recent call last):
  File "/Users/charles/.pyenv/versions/3.10.6/lib/python3.10/runpy.py", line 187, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/Users/charles/.pyenv/versions/3.10.6/lib/python3.10/runpy.py", line 110, in _get_module_details
    __import__(pkg_name)
  File "/private/tmp/data_example/data_example.py", line 19, in <module>
    app = Litestar(
  File "/private/tmp/data_example/lib/python3.10/site-packages/litestar/app.py", line 500, in __init__
    self.register(route_handler)
  File "/private/tmp/data_example/lib/python3.10/site-packages/litestar/app.py", line 709, in register
    route.create_handler_map()
  File "/private/tmp/data_example/lib/python3.10/site-packages/litestar/routes/http.py", line 98, in create_handler_map
    kwargs_model = route_handler.create_kwargs_model(path_parameters=self.path_parameters)
  File "/private/tmp/data_example/lib/python3.10/site-packages/litestar/handlers/base.py", line 577, in create_kwargs_model
    return KwargsModel.create_for_signature_model(
  File "/private/tmp/data_example/lib/python3.10/site-packages/litestar/_kwargs/kwargs_model.py", line 362, in create_for_signature_model
    is_data_optional=field_definitions["data"].is_optional if "data" in expected_reserved_kwargs else False,
KeyError: 'data'

Screenshots

No response

Logs

Litestar Version

2.16.0

Platform

• Linux
• Mac
• Windows
• Other (Please specify in the description above)

[euri10]

The litestar documentation suggests that one can use the reserved 'data' kwarg in a dependency function. My attempt to do so results in an exception, traceback included below.

hello, where do we say that please ?

[declaresub]

Go to https://docs.litestar.dev/2/usage/dependency-injection.html#dependency-keyword-arguments ; in particular,

In fact, you can inject the same data that you can inject into route handlers.

Follow this link, where one finds

The following sources can be accessed using annotated function kwargs:

path, query, header, and cookie parameters
requests
injected dependencies

Now follow the second link [requestts] in this list --

The body of HTTP requests can be accessed using the special data parameter in a handler function.

[jberkow713]

You could just make a key check to remove all chance of errors like this, by altering the code in the kwargs_model.py , line 360 from

'is_data_optional=field_definitions["data"].is_optional if "data" in expected_reserved_kwargs else False,'

to:
if "data" in expected_reserved_kwargs and 'data' in field_definitions.keys():
is_data_optional=field_definitions["data"].is_optional
else:
is_data_optional=False

Then just return this variable in the return KwargsModel tuple, as done before.

Looks like the error came about because if data was in expected_reserved_kwargs, it was implied that it would be in the field_definitions, and it wasn't.

[github-actions]

A fix for this issue has been released in v2.18.0