Is it possible to register a background task before raising an HTTP error?

[jandix]

First check

• I used the GitHub search to find a similar issue and didn't find it.
• I searched the FastAPI documentation, with the integrated search.
• I already searched in Google "How to X in FastAPI" and didn't find any information.

Description

Currently, I am trying to implement an email verfication resource which automatically sends a new email using SendGrid (using the SendGrid API client). The email is created but the send_sendgrid task is never executed. The setting works just fine when I am using the setup as described in the documentation and returning a response. Is it possible that the thread is killed after calling raise? Is there any possibilty to execute the email function as a background task although using raise?

Additional context

@router.post("/verify/{token}/", status_code=204, response_model=None)
def verify_email(token: str,
                 background_tasks: BackgroundTasks,
                 session: Session = Depends(get_session)) -> None:
    # get email confirmation
    email_confirmation = CRUDEmailConfirmation(session=session).read(token=token)

    # return error if no token
    if not email_confirmation:
        raise HTTPException(status_code=400, detail="Token not valid.")

    # check if token is still valid else send new email
    if is_datetime_expired(email_confirmation.created_at):
        # extract user id
        user = email_confirmation.user

        # remove old token
        CRUDEmailConfirmation(session=session).remove(email_confirmation_id=email_confirmation.id)

        # create new token
        email_confirmation = CRUDEmailConfirmation(session=session).create(user=user)

        # prepare confirmation email
        email = Email(receiver=email_confirmation.user.email,
                      subject="Please confirm your email address",
                      message="")
        email.use_template(template="registration.jinja2",
                           token=email_confirmation.token,
                           url=CLIENT_URL)

        # queue email to background tasks
        background_tasks.add_task(email.send_sendgrid)

        # return error message
        raise HTTPException(status_code=400, detail="Token not valid.")

    # update email confirmation
    CRUDUser(session=session).update(user_id=email_confirmation.user.id,
                                     user=SchemaUserUpdate(is_email_verified=True))

    # delete token
    CRUDEmailConfirmation(session=session).remove(email_confirmation_id=email_confirmation.id)
    return None

[tiangolo]

So, the background tasks are attached to the response. Once the response is sent successfully, all the background tasks are executed.

But raising an exception is a way of saying "stop and abort everything here, something was wrong", so, the original response (that is what contains the background tasks) is never returned, and those background tasks are never executed.

I think I can imagine how it could be useful to run background tasks after raising something, but I can also see how the current default behavior could still be useful.

I see 2 alternatives to solve your use case.

One is to return a response directly, with a status code of 400. The benefit of raising is just that it aborts anything else, so it can be used even inside of deeply nested dependencies. But in the end, it is just converted to a normal response using a status code of 400, so you could just return it directly.

The other option is to create your own custom exception that could include some background tasks and raise it. And then use a custom handler to get the exception, extract the background tasks, and return any relevant response with its custom background tasks: https://fastapi.tiangolo.com/tutorial/handling-errors/#install-custom-exception-handlers

[github-actions[bot]]

Assuming the original issue was solved, it will be automatically closed now. But feel free to add more comments or create new issues.

[OpetherMB]

So, the background tasks are attached to the response. Once the response is sent successfully, all the background tasks are executed.

But raising an exception is a way of saying "stop and abort everything here, something was wrong", so, the original response (that is what contains the background tasks) is never returned, and those background tasks are never executed.

I think I can imagine how it could be useful to run background tasks after raising something, but I can also see how the current default behavior could still be useful.

I see 2 alternatives to solve your use case.

One is to return a response directly, with a status code of 400. The benefit of raising is just that it aborts anything else, so it can be used even inside of deeply nested dependencies. But in the end, it is just converted to a normal response using a status code of 400, so you could just return it directly.

The other option is to create your own custom exception that could include some background tasks and raise it. And then use a custom handler to get the exception, extract the background tasks, and return any relevant response with its custom background tasks: https://fastapi.tiangolo.com/tutorial/handling-errors/#install-custom-exception-handlers

thank you for your answer, can you please emphasis this in the docs please i spent too much time on a pblm that raise an exception and abort the background tasks if only this was clearer at least for people like me ...and really man thank you for evthg ur awesome

[NikBez]

background_tasks.add_task(email.send_sendgrid) -> asyncio.create_task(email.send_sendgrid)