[Bug] exceptions's traceback are silently ignored with router in handle_request_async

[flapili]

Environment

Python 3.14.4 on Macos,
1.0.0rc1 + starlette 0.46.2 (as extra)

Bug Description

Hi, I'm trying FastOpenAPI for a poc and to return in my first love language 😅

when an unhandled exception in raised in FastOpenAPI's routers the behavior of errors handling differ from default/builtin, may lead to difficulties to identifies root cause of 500 without wrapping the whole handler code in try + log + re raise

pure starlette => print the stacktrace to stderr
with FastOpenApi => only access log show the 500 status code

I digged a bit with starlette but I believe all others frameworks are affected, it's not related to the asgi server as uvicorn and granian show the same issue, aiohttp too (however I did not check if aiohttp print traceback by default)

was able to isolate the cause to BaseAdapter.handle_request_async that eat the exception to build http error

then i'm wondering if it's not possible to have generic error handling regardless of the framework, it could just be a callable attached to the router

I'm open to contribute and make a PR I just want to ensure this feature would be suitable and not too out of scope of original lib goal

Steps to Reproduce

import logging
from fastopenapi import Response
import inspect
from fastopenapi.routers import StarletteRouter
from starlette.applications import Starlette
from starlette.responses import JSONResponse
from starlette.routing import Route


async def root(_request):
    1 / 0
    return JSONResponse(content={"hello": "world"})


app = Starlette(
    debug=True,
    routes=[
        Route("/1", root),
    ],
)

router = StarletteRouter(app=app)


@router.get("/2")
async def root_fastopenapi():
    1 / 0
    return JSONResponse({"hello": "world"})


async def handle_request_async(endpoint, env):
    """Handle asynchronous request"""
    try:
        request_data = await router.extractor_async_cls.extract_request_data(env)
        kwargs = await router.req_param_resolver_cls.resolve_async(
            endpoint, request_data
        )
        if inspect.iscoroutinefunction(endpoint):
            result = await endpoint(**kwargs)
        else:
            result = endpoint(**kwargs)
        route_meta = endpoint.__route_meta__
        response_model = route_meta.get("response_model")
        if response_model:
            result = router._validate_response(result, response_model)
        if router.is_framework_response(result):
            return result
        response = router.response_builder_cls.build(result, route_meta)
        if route_meta.get("status_code") == 204:
            response.content = None
        return router.build_framework_response(response)
    except Exception as e:
        logging.exception(e, exc_info=True) # <- e is used to build api response but not used at all for debugging purpose
        return router.build_framework_response(
            Response(
                content="ugly monkeypatch",
                status_code=500,
            )
        )

router.handle_request_async = handle_request_async

GET /1 => logged error and return 500 to client
GET /2 => return 500 to client but silent underlying error

Logs or Tracebacks

N/A 

Contact

@ mention me on github

[mr-fatalyst]

Hi @flapili, confirmed and thanks for the clean repro: both handle_request and handle_request_async convert the exception into the HTTP response but never log it, while native Starlette re-raises and lets uvicorn print the traceback. Since the code lives in the shared BaseAdapter, every framework is affected, not just Starlette. I'll fix it in the next rc by logging the traceback for unexpected 5xx via a fastopenapi logger, which restores the native behavior.

[flapili]

Hi, thanks for the quick reply :)

would a configurable callable to handle exceptions be suitable or should it be framework specific with their own ways ?

could be

async def handle_exc(exc: Exception, router: BaseRouter):
   raise exc

by default and then

except Exception as e:
   asyncio.create_task(self.error_handler(e, self))
   return router.build_framework_response(...)

as FastOpenAPI wrap endpoints in a already standardized way across frameworks we could immagine hooks that allow adding any sort of custom logging (gcp logging, aws cloudwatch, ...) regardless of the server or interface (aiohttp, tornado, asgi and wsgi) or even before/after hooks

Are you open to this kind of features or do you prefer limit the scope to openapi ?

In case you'r fine with that kind of feature I would be happy to implement it

[mr-fatalyst]

Thanks, the configurable hook idea is interesting and fits how I think about the library. The whole point of FastOpenAPI is that request handling works the same way across every framework, so a single place to plug in your own error logic (logging, Sentry, GCP, CloudWatch) lines up well with that approach. So yes, I'm open to a feature like this.

That said, there are a few problems with the specific sketch worth pointing out. The main one is that asyncio.create_task would break the synchronous frameworks. The sync path (Flask, Django in sync mode, Falcon in sync mode) runs under WSGI with no running event loop, so create_task there just raises RuntimeError: no running event loop. Since the hook is meant to behave the same everywhere, it has to work in the sync path too.

The second problem is that create_task is fire and forget. The task gets detached, exceptions raised inside it are lost, and there's no guarantee it even finishes before the worker moves on. That's unreliable for logging, and it doesn't work at all for the before/after hooks you mention, because by that point the response is already built and returned, so the hook can't influence it anymore.

And a third point: a default of raise exc inside create_task doesn't do what it looks like. It isn't a re-raise up to the server the way native Starlette does it, it's just an unhandled exception in a detached task, so it never propagates anywhere.

So the direction I'm leaning toward is this. The hook gets called inline inside the except block, not through create_task, so it actually runs and can optionally influence the response. I'd support both sync and async callbacks (await the coroutine on the async path, call it directly on the sync path, exactly like the library already does when an async endpoint is used with a sync router). The response behavior stays standardized as it is today, and on top of that I'll add logging for 5xx errors, so nothing breaks for anyone.

I'll try to get the logging fix out in the next few days, since it closes the original bug on its own, and the hook can land separately afterwards.

[mr-fatalyst]

@flapili i I added this logic on master. You can check your case with:
pip install "fastopenapi @ git+https://github.com/mr-fatalyst/fastopenapi.git@master"
Thanks again!