Reraise exception from background task

[Kludex]

• Closes middleware causes exceptions to not be raised/handled silently (back again) #2625

Currently, the exceptions on the background tasks are swallowed:

from typing import Any

from starlette.applications import Starlette
from starlette.background import BackgroundTask
from starlette.middleware import Middleware
from starlette.middleware.base import BaseHTTPMiddleware
from starlette.requests import Request
from starlette.responses import JSONResponse
from starlette.routing import Route


class CustomHeaderMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request: Request, call_next: Any):
        response = await call_next(request)
        return response


async def bg_task():
    print("hi there")
    raise ValueError("TEST")


def homepage(request: Request):
    task = BackgroundTask(bg_task)
    message = {"status": "Ok"}
    return JSONResponse(message, background=task)


routes = [Route("/", homepage)]

middleware = [Middleware(CustomHeaderMiddleware)]

app = Starlette(routes=routes, middleware=middleware)

[Kludex]

Ignore this. It was just getting me crazy.

[Kludex]

Ignore this. It was just getting me crazy.

[Kludex]

Ignore this. It was just getting me crazy.

[Kludex]

If you uncomment those lines, you can see that we have the exceptions on the app_exc, but we don't reraise them at any point.

[Kludex]

It looks like this is enough to make the switch so we have time to run the coro task after the break above.

This shouldn't be the way to solve this issue... Also, it breaks one of the tests.

[ojii]

doesn't this only work because in the test case in the PR description, the background task that fails isn't really async so a single task switch (via sleep(0)) is enough to trigger the exception, but a background task that does await would still not be triggered by this?

Assuming await self.app finishes all background tasks, the coro that awaits the app here could signal an event that can be awaited here instead.

[Kludex]

@jhominal Any idea here?

[adriangb]

@Kludex would #2176 resolve this?