Why global_middleware is not being called when using enable_validation=True?

[claudiobusatto]

Hello!

I have a pretty basic code which includes a global_middleware to my API Gateway resolver and a router which also adds a router_middleware to POST / route.

The app uses the enable_validation=True and I noticed that if the validation fails, both global_middleware and router_middleware are not executed. I have logs inside the middlewares and I can't see any of them.

I was expecting the order to be: global_middleware -> route_middleware -> "pydantic validation middleware". But it seems to start with the pydantic validation middleware one.

Is it expected or is there something I'm missing?

Like, is it correct that the request validation happens before everything else?
If you have an authentication process as a global middleware, shouldn't it be executed before anything else?

# app.py
app = APIGatewayRestResolver(enable_validation=True)
app.use(middlewares=[global_middleware])

app.include_router(router)

# router.py
router = Router()

@router.post(
    "/",
    middlewares=[router_middleware],
    summary="A route summary",
    description="A route description",
    response_description="A route response description",
    responses={
        200: {
            "description": "Success",
            "content": {"application/json": {"model": SuccessOutput}},
        },
        422: {
            "description": "Unprocessable Entity",
            "content": {"application/json": {"model": InternalServerErrorOutput}},
        },
        500: {
            "description": "Internal service error",
            "content": {"application/json": {"model": InternalServerErrorOutput}},
        },
    },
    tags=["tag"],
)
@tracer.capture_method
def post(
    name: str,
    data: InputData,
    metadata: InputMetadata,
):
    return "post"    

[heitorlessa]

Hey Claudio, could you convert this into a feature request please? The way data validation was implemented (middleware) it runs before any other, and a validation fail short-circuits the logic. We could look into a backwards compatible solution for this. Another customer wanted this for authorisation (Discord server) but it turned out it was best as a Lambda Authorizer whereas your case is valid and we should support

…

On Fri, 28 Jun 2024 at 15:59, Claudio Busatto ***@***.***> wrote: Hello! I have a pretty basic code which includes a global_middleware to my API Gateway resolver and a router which also adds a router_middleware to POST / route. The app uses the enable_validation=True and I noticed that if the validation fails, both global_middleware and router_middleware are not executed. Is it expected or is there something I'm missing? Like, is it correct that the request validation happens before everything else? If you have an authentication process as a global middleware, should it be executed after a request data validation? # app.pyapp = APIGatewayRestResolver(enable_validation=True)app.use(middlewares=[global_middleware]) app.include_router(router) # router.pyrouter = Router() @router.post( "/", middlewares=[router_middleware], summary="A route summary", description="A route description", response_description="A route response description", responses={ 200: { "description": "Success", "content": {"application/json": {"model": SuccessOutput}}, }, 422: { "description": "Unprocessable Entity", "content": {"application/json": {"model": InternalServerErrorOutput}}, }, 500: { "description": "Internal service error", "content": {"application/json": {"model": InternalServerErrorOutput}}, }, }, ***@***.***_methoddef post( name: str, data: InputData, metadata: InputMetadata, ): return "post" — Reply to this email directly, view it on GitHub <#4656>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZPQBDNCD3WCZIW735M3RDZJVT5NAVCNFSM6AAAAABKB6YU5GVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWHA3TGNZRHA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[heitorlessa]

Part of the impediment in the last discussion on Discord was the lack of feedback on whether customers would want any middleware with bad input to be called regardless OR short-circuit to prevent further processing and latency.

The way it got implemented was non-intentional to behave this way

[tlinhart]

I was just about to ask that but found a workaround. Here's what I ended up with (including the explaining comment):

# Place the middleware at the very top of the stack to ensure that every
# request is intercepted. If we used app.use(middlewares=[...]) some built-in
# global middlewares could short-circuit the processing before reaching this
# one (e.g. validation middlewares).
app._router_middlewares.insert(0, LogRequestMiddleware())

For sure it's not the clean solution as it abuses "private" variable. But works for now.

The use() method could probably be extended in a backwards compatible way to accept other parameter which could specify the insertion place (either exact or relative to know classes of middlewares, e.g. built-in global middlewares, validation middlewares, route specific middlewares etc.)