Possible to execute a function after returning a response inside a route?

[coltonbh]

First Check

• I added a very descriptive title to this issue.
• 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.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to FastAPI but to Pydantic.
• I already checked if it is not related to FastAPI but to Swagger UI.
• I already checked if it is not related to FastAPI but to ReDoc.

Commit to Help

• I commit to help with one of those options 👆

Example Code

from fastapi import FastAPI

app = FastAPI()


@app.get("/")
async def root():
    try:
        return {"message": "Hello World"}
    except Exception:
        pass
    else:
        print("I'm executing after successfully returning a response")
    finally:
        print("I'm executing after a successful or failed response")

Description

I would like to execute a particular action after a response has been successfully returned. My use case is that the end user attempts to retrieve an object via FastAPI from my in memory database. Only if the response succeeds, then I'd like to remove the object from the database. I only want to remove the item after successfully returning a response, as responses may fail due to idiosyncrasies in the user's connection.

Is there a "FastAPI" way to do this? It seems straightforward but I can't find anything related to this in the documentation after searching the docs for the words "finally" and "except".

If there's not a "FastAPI" way to do this, any other more general approach to achieve this you might recommend?

Much thanks! 🙏🏼

Operating System

Linux

Operating System Details

No response

FastAPI Version

0.65.1

Python Version

3.9.8

Additional Context

No response

[yinziyan1206]

add BaseHTTPMiddleware or using exception handler

[jacksbox]

you can use Background Tasks for this - https://fastapi.tiangolo.com/tutorial/background-tasks/ - they do exactly what you require - execute code just after successful return

[coltonbh]

you can use Background Tasks for this - https://fastapi.tiangolo.com/tutorial/background-tasks/ - they do exactly what you require - execute code just after successful return

@jacksbox wouldn't this create a race condition? I kick off the background task before returning the response, the background task will likely complete quickly (it's just an in memory DB delete) and the response may fail a few seconds after the fact?

@yinziyan1206 I'll take a look at these objects! It appeared the exception handler would only execute if an exception were raised inside the response function, correct?

And thank you both for your responses!

[coltonbh]

@yinziyan1206 it appears middleware cannot solve the problem:

A "middleware" is a function that works with every request before it is processed by any specific path operation. And also with every response before returning it.

https://fastapi.tiangolo.com/tutorial/middleware/?h=middlewa#middleware

[yinziyan1206]

Yes, you can use exception handler to do some something when catching exception. And middleware is like a decorator, or a wrapper when receiving request. You can handle a request or the response, like making a wrapper for call_next(Request)

[coltonbh]

@yinziyan1206 do you know what exception is raised if a client connection is cut before the full response has returned? This would be helpful.

It appears from the docs that the middleware only operates before returning a response. I.e., I can operate on the response object and then return it to the end user. However, I'd like to execute code after successfully returning a response to the client app. I do not want to delete the data from my DB before knowing it has been successfully returned to the end user.

I'm looking at these docs to come to this conclusions:

A "middleware" is a function that works with every request before it is processed by any specific path operation. And also with every response before returning it.

- It takes each request that comes to your application.
- It can then do something to that request or run any needed code.
- Then it passes the request to be processed by the rest of the application (by some path operation).
- It then takes the response generated by the application (by some path operation).
- It can do something to that response or run any needed code.
- Then it returns the response.

[jacksbox]

@coltonbh according to the fastapi docs (and the starelette docs, the underlying implementation https://www.starlette.io/background/) background tasks get only executed after the response is send to the client - if there is an exception somewhere inside the fastapi app, the task does not execute...

Or do you really want to check if a response arrives at the client? the only way to do that is on the client I guess...

[yinziyan1206]

@coltonbh according to the fastapi docs (and the starelette docs, the underlying implementation https://www.starlette.io/background/) background tasks get only executed after the response is send to the client - if there is an exception somewhere inside the fastapi app, the task does not execute...

Or do you really want to check if a response arrives at the client? the only way to do that is on the client I guess...

@coltonbh That's right. And you can try this example.

@app.middleware("http")
async def middleware(request: Request, call_next):
    try:
        return await call_next(request)
    finally:
        print('ok')
        del request

and it work when catching exception

[coltonbh]

Thanks for your responses! Will have a second to play with this later this week and try it out :) Will report back!

[coltonbh]

@jacksbox yes I'd like to really check that the response arrives at the client! Otherwise I won't want to delete the data they are requesting.

Turns out the BackgroundTask does this perfectly. If the request is prematurely terminated by the client (say for a connection issue, or timeout) the BackgroundTask does not execute. And the BackgroundTask does not start execution until after the successful return of the response. The following code show a working example:

from time import sleep
from fastapi import FastAPI, BackgroundTasks, Request

app = FastAPI()

def delete_objects(filename: str):
    print(f"Deleting: {filename}")

@app.get("/")
async def root(background_tasks: BackgroundTasks):
    sleep(3)
    background_tasks.add_task(delete_objects, "my filename")
    return {"hello": "world"}

And on the client side:

import httpx

# Response is returned and the background task will execute
r = httpx.get("http://localhost:8000", timeout=5)

# Response not returned due to client termination and the background task will not execute
r = httpx.get("http://localhost:8000", timeout=2)

The same correct behavior will occur is the client manually terminates the connection with a ctrl + c while the response is in flight.

@yinziyan1206 Thanks for the suggestions on the middleware. The middleware doesn't follow the same paradigm for execution: the finally clause will execute no matter the success/failure of the request and middleware appears to not support try/except/else/finally clauses beyond try/finally. Here's an example that demonstrates this:

from time import sleep
from fastapi import FastAPI, BackgroundTasks, Request

app = FastAPI()

@app.middleware("http")
async def middleware(request: Request, call_next):
    try:
        print("in try")
        return await call_next(request)
    except Exception:
        print("Don't delete the file because the client did not get it!")
    else:
        print("Delete the file!")
    finally:
        print("In finally!")

@app.get("/")
async def root(background_tasks: BackgroundTasks):
    sleep(3)
    return {"hello": "world"}

If you do the same requests noted above with the httpx client you will never reach the else or except blocks of the middleware. However the finally block will always execute after a request, so this seems like a great way to cleanup any state that is associated with a request; however, it cannot trigger different behaviors for when a request succeeds and when it fails. Let me know if I'm missing anything here and thank you for your thoughtful feedback and suggestions.

The BackgroundTask meets the specs I was looking for:

1. Execute if request is successful
2. Do not execute if request fails due to client-side termination or connection issues (not just server-side exceptions).

If I've inaccurately summarized your suggestions or findings please let me know and I'll update my response. Thanks to you both very much!

[besarthoxhaj]

@coltonbh

Thank you for providing the example but upon trying it myself I noticed it doesn't really work i.e. the background task is indeed ran twice.

Do you maybe spot anything different I might have copied wrong?

[coltonbh]

Oooof. @besarthoxhaj you're right! I'm not sure why I was so confident this worked before--I even tried with the same older (0.65.0) version of fastapi I was running back then... Even though the client times out fastapi returns a 200 and then executes the background task. I'm not sure to "where" fastapi is returning the response since the client has cut the connection...

Perhaps there is no way to know that the request has truly succeeded? It appears both the BackgroundTask and middleware approach suffer from the same issue--a cut connection still appears "successful" to fastapi since no exception is raised on the server. Yes?

[besarthoxhaj]

@coltonbh I might have a look later and see if I can help

[AntonOfTheWoods]

I was also looking for this but... upon further reflection, isn't it just much better to let the client do another request after the client knows it has successfully received and processed the first query? After all, if we want to make sure the client has successfully been given the content of a request, how do we know that the request hasn't been successfully received by the client but then the client died before it could do what it needed to do? The server simply can't know that... unless the client tells it.

So unless there is some ridiculous clause the lawyers put in referring to tcp acks being received that the data was "sent" (so we get our $$$), I'm not so sure I see this as a valid usecase anymore...

[pavs94]

This is exactly what I'm dealing with. The Client is expecting an ACK within SLA without even letting is check if the request is valid. Their SLA is 100ms which is impossible to achieve with multiple API and DB calls happening internally.