104

I have some code that needs to execute after Flask returns a response. I don't think it's complex enough to set up a task queue like Celery for it. The key requirement is that Flask must return the response to the client before running this function. It can't wait for the function to execute.

There are some existing questions about this, but none of the answers seem to address running a task after the response is sent to the client, they still execute synchronously and then the response is returned.

Andrey Glazkov
  • 2,398
  • 3
  • 17
  • 19
Brandon Wang
  • 3,701
  • 7
  • 31
  • 36

10 Answers10

132

The long story short is that Flask does not provide any special capabilities to accomplish this. For simple one-off tasks, consider Python's multithreading as shown below. For more complex configurations, use a task queue like RQ or Celery.

Why?

It's important to understand the functions Flask provides and why they do not accomplish the intended goal. All of these are useful in other cases and are good reading, but don't help with background tasks.

Flask's after_request handler

Flask's after_request handler, as detailed in this pattern for deferred request callbacks and this snippet on attaching different functions per request, will pass the request to the callback function. The intended use case is to modify the request, such as to attach a cookie.

Thus the request will wait around for these handlers to finish executing because the expectation is that the request itself will change as a result.

Flask's teardown_request handler

This is similar to after_request, but teardown_request doesn't receive the request object. So that means it won't wait for the request, right?

This seems like the solution, as this answer to a similar Stack Overflow question suggests. And since Flask's documentation explains that teardown callbacks are independent of the actual request and do not receive the request context, you'd have good reason to believe this.

Unfortunately, teardown_request is still synchronous, it just happens at a later part of Flask's request handling when the request is no longer modifiable. Flask will still wait for teardown functions to complete before returning the response, as this list of Flask callbacks and errors dictates.

Flask's streaming responses

Flask can stream responses by passing a generator to Response(), as this Stack Overflow answer to a similar question suggests.

With streaming, the client does begin receiving the response before the request concludes. However, the request still runs synchronously, so the worker handling the request is busy until the stream is finished.

This Flask pattern for streaming includes some documentation on using stream_with_context(), which is necessary to include the request context.

So what's the solution?

Flask doesn't offer a solution to run functions in the background because this isn't Flask's responsibility.

In most cases, the best way to solve this problem is to use a task queue such as RQ or Celery. These manage tricky things like configuration, scheduling, and distributing workers for you.This is the most common answer to this type of question because it is the most correct, and forces you to set things up in a way where you consider context, etc. correctly.

If you need to run a function in the background and don't want to set up a queue to manage this, you can use Python's built in threading or multiprocessing to spawn a background worker.

You can't access request or others of Flask's thread locals from background tasks, since the request will not be active there. Instead, pass the data you need from the view to the background thread when you create it.

@app.route('/start_task')
def start_task():
    def do_work(value):
        # do something that takes a long time
        import time
        time.sleep(value)

    thread = Thread(target=do_work, kwargs={'value': request.args.get('value', 20)})
    thread.start()
    return 'started'
Tim Stack
  • 3,209
  • 3
  • 18
  • 39
Brandon Wang
  • 3,701
  • 7
  • 31
  • 36
  • 4
    This is a solution but not the complete solution, what happens when the child thread encounters exception? So we have to handle that too, Solution will be to use a custom thread class instead of default Thread class and handle the exception in there. – H S Rathore Aug 02 '18 at 13:06
  • 18
    I love how you explained why 'after_request' and 'teardown_request' don't achieve what the questioner's asking for, because all ove stackoverflow people have mentioned these two as the solutions. – pedram bashiri Aug 06 '20 at 20:16
45

Flask is a WSGI app and as a result it fundamentally cannot handle anything after the response. This is why no such handler exists, the WSGI app itself is responsible only for constructing the response iterator object to the WSGI server.

A WSGI server however (like gunicorn) can very easily provide this functionality, but tying the application to the server is a very bad idea for a number of reasons.

For this exact reason, WSGI provides a spec for Middleware, and Werkzeug provides a number of helpers to simplify common Middleware functionality. Among them is a ClosingIterator class which allows you to hook methods up to the close method of the response iterator which is executed after the request is closed.

Here's an example of a naive after_response implementation done as a Flask extension:

import traceback
from werkzeug.wsgi import ClosingIterator

class AfterResponse:
    def __init__(self, app=None):
        self.callbacks = []
        if app:
            self.init_app(app)

    def __call__(self, callback):
        self.callbacks.append(callback)
        return callback

    def init_app(self, app):
        # install extension
        app.after_response = self

        # install middleware
        app.wsgi_app = AfterResponseMiddleware(app.wsgi_app, self)

    def flush(self):
        for fn in self.callbacks:
            try:
                fn()
            except Exception:
                traceback.print_exc()

class AfterResponseMiddleware:
    def __init__(self, application, after_response_ext):
        self.application = application
        self.after_response_ext = after_response_ext

    def __call__(self, environ, after_response):
        iterator = self.application(environ, after_response)
        try:
            return ClosingIterator(iterator, [self.after_response_ext.flush])
        except Exception:
            traceback.print_exc()
            return iterator

You can use this extension like this:

import flask
app = flask.Flask("after_response")
AfterResponse(app)

@app.after_response
def say_hi():
    print("hi")

@app.route("/")
def home():
    return "Success!\n"

When you curl "/" you'll see the following in your logs:

127.0.0.1 - - [24/Jun/2018 19:30:48] "GET / HTTP/1.1" 200 -
hi

This solves the issue simply without introducing either threads (GIL??) or having to install and manage a task queue and client software.

Matthew Story
  • 3,573
  • 15
  • 26
  • 2
    how could i use this inside a blueprint? – xiangzuomanongerbude Aug 13 '18 at 06:14
  • 6
    How do I use this with an argument in the route("/") that needs to be passed to the after_response function? – EmperorPenguin Feb 02 '19 at 07:09
  • 1
    Is there some reason why this wouldn't work as described running in a WSGI Container? Running this in a Flask docker container is not yielding the expected results, and I am seeing the after_response get executed before the client gets the response. When I run the code in debug mode, without WSGI, it executes as expected. – theMJof91 Nov 15 '19 at 15:06
  • This definitely works after the response, but the output may not show the log entry until after the request finishes processing. At least in my setup the logging happens after the after_response is complete. – edA-qa mort-ora-y May 27 '21 at 18:32
  • It doesn't work if home() raises an exception – pmiguelpinto90 Sep 28 '21 at 10:00
  • How do I give the after_response function access to data that is passed to the home() function? –  Aug 24 '22 at 16:41
19

Flask now supports (via Werkzeug) a call_on_close callback decorator on response objects. Here is how you use it:

@app.after_request
def response_processor(response):
    # Prepare all the local variables you need since the request context
    # will be gone in the callback function

    @response.call_on_close
    def process_after_request():
        # Do whatever is necessary here
        pass

    return response

Advantages:

  1. call_on_close sets up functions for being called after the response is returned, using the WSGI spec for the close method.

  2. No threads, no background jobs, no complicated setup. It runs in the same thread without blocking the request from returning.

Disadvantages:

  1. No request context or app context. You have to save the variables you need, to pass into the closure.
  2. No local stack as all that is being torn down. You have to make your own app context if you need it.
  3. Flask-SQLAlchemy will fail silently if you're attempting to write to the database (I haven't figured out why, but likely due to the context shutting down). (It works, but if you have an existing object, it must be added to the new session using session.add or session.merge; not a disadvantage!)
Kiran Jonnalagadda
  • 2,606
  • 1
  • 30
  • 29
  • 1
    this doesn't work. the function decorated by `call_on_close` is executed before the response is returned. – djh Sep 21 '20 at 13:34
  • 3
    I just tested again by adding a `time.sleep` call followed by `print` in the `call_on_close` handler. It distinctly runs after the response has been returned. – Kiran Jonnalagadda Sep 23 '20 at 21:21
  • However, it's possible different WSGI servers will implement this differently. My test here is using the Werkzeug debug server. – Kiran Jonnalagadda Sep 25 '20 at 09:17
  • I don't know flask or Werkzeug well enough to be sure if this means anything, but the callbacks passed to `call_on_close()` [do appear to be triggered when `__exit__` is called](https://github.com/pallets/werkzeug/blob/669323cf3c9c9241522e16a8a445450a0b9a55c9/src/werkzeug/wrappers/base_response.py#L577), which I would assume is after the response has been returned. – Christian Reall-Fluharty Dec 29 '20 at 21:37
  • I confirm that, Flask-SQLAlchemy will fail silently if you're attempting to write to the database (I haven't figured out why, but likely due to the context shutting down). (It works, but if you have an existing object, it must be added to the new session using session.add or session.merge; not a disadvantage!) – Linh Nguyễn Ngọc Jun 04 '21 at 03:42
  • The trigger point as document in Flask is during close time for the Response rapper. Meaning it is ready to be sent but may not have actually transmitted just yet depending on the internals. You can use this for cleanup but assuming anything regarding the timing of the actual network transmission. You cann't affect that here. – wheredidthatnamecomefrom Aug 06 '21 at 20:40
  • 2
    regarding disadvantage #2, you can use `@flask.copy_current_request_context` decorator to propagate the request context – Daniel Braun Feb 10 '22 at 14:39
13

There are 3 ways to do this, all work:

1. Thread

@app.route('/inner')
def foo():
    for i in range(10):
        sleep(1)
        print(i)
    return 

@app.route('/inner', methods=['POST'])
def run_jobs():
    try:
        thread = Thread(target=foo)
        thread.start()
        return render_template("index_inner.html", img_path=DIR_OF_PHOTOS, video_path=UPLOAD_VIDEOS_FOLDER)
                            

2. AfterResponse decorator

app = Flask(__name__)
AfterResponse(app)

@app.route('/inner', methods=['POST'])
def save_data():
    pass

@app.after_response
def foo():
    for i in range(10):
        sleep(1)
        print(i)
    return 

3. call_on_close

from time import sleep

from flask import Flask, Response, request


app = Flask('hello')


@app.route('/')
def hello():

    response = Response('hello')

    @response.call_on_close
    def on_close():
        for i in range(10):
            sleep(1)
            print(i)

    return response


if __name__ == '__main__':
    app.run()
mousetail
  • 7,009
  • 4
  • 25
  • 45
8

Middleware Solution for Flask Blueprints

This is the same solution proposed by Matthew Story (which is the perfect solution IMHO - thanks Matthew), adapted for Flask Blueprints. The secret sauce here is to get hold of the app context using the current_app proxy. Read up here for more information (http://flask.pocoo.org/docs/1.0/appcontext/)

Let's assume the AfterThisResponse & AfterThisResponseMiddleware classes are placed in a module at .utils.after_this_response.py

Then where the Flask object creation occurs, you might have, eg...

__init__.py

from api.routes import my_blueprint
from .utils.after_this_response import AfterThisResponse

app = Flask( __name__ )
AfterThisResponse( app )
app.register_blueprint( my_blueprint.mod )

And then in your blueprint module...

a_blueprint.py

from flask import Blueprint, current_app

mod = Blueprint( 'a_blueprint', __name__, url_prefix=URL_PREFIX )

@mod.route( "/some_resource", methods=['GET', 'POST'] )
def some_resource():
    # do some stuff here if you want

    @current_app.after_this_response
    def post_process():
        # this will occur after you finish processing the route & return (below):
        time.sleep(2)
        print("after_response")

    # do more stuff here if you like & then return like so:
    return "Success!\n"
Paul Brackin
  • 339
  • 3
  • 5
  • 1
    Your approach is very nice, but your answer is not complete. Could you answer the full solution? Is better not to depend from other answer, and is also better for clarify. Also you used different names __my_blueprint__ and __a_blueprint__ that leads to confussion. – Rutrus Feb 21 '21 at 08:53
  • Do you have the code for `AfterThisResponse` available, as Matthew's code is for `AfterResponse` which is for every response. – edA-qa mort-ora-y May 27 '21 at 18:48
6

In addition to the other solutions, you can do route specific actions by combining after_this_request and response.call_on_close:

@app.route('/')
def index():
    # Do your pre-response work here
    msg = 'Hello World!'
    @flask.after_this_request
    def add_close_action(response):
        @response.call_on_close
        def process_after_request():
            # Do your post-response work here
            time.sleep(3.0)
            print('Delayed: ' + msg)
        return response
    return msg
VoteCoffee
  • 4,692
  • 1
  • 41
  • 44
3

Thanks to Matthew Story and Paul Brackin, but I needed to change their proposals. So the working solution is:

.
├── __init__.py
├── blueprint.py
└── library.py
# __init__.py
from flask import Flask
from .blueprint import bp
from .library import AfterResponse

app = Flask(__name__)

with app.app_context():
    app.register_blueprint(bp, url_prefix='/')
    AfterResponse(app)
# blueprint.py
from flask import Blueprint, request, current_app as app
from time import sleep

bp = Blueprint('app', __name__)


@bp.route('/')
def root():
    body = request.json

    @app.after_response
    def worker():
        print(body)
        sleep(5)
        print('finished_after_processing')

    print('returned')
    return 'finished_fast', 200
# library.py
from werkzeug.wsgi import ClosingIterator
from traceback import print_exc


class AfterResponse:
    def __init__(self, application=None):
        self.functions = list()
        if application:
            self.init_app(application)    

    def __call__(self, function):
        self.functions.append(function)

    def init_app(self, application):
        application.after_response = self
        application.wsgi_app = AfterResponseMiddleware(application.wsgi_app, self)

    def flush(self):
        while self.functions:
            try:
                self.functions.pop()()
            except Exception:
                print_exc()


class AfterResponseMiddleware:
    def __init__(self, application, after_response_ext):
        self.application = application
        self.after_response_ext = after_response_ext

    def __call__(self, environ, after_response):
        iterator = self.application(environ, after_response)
        try:
            return ClosingIterator(iterator, [self.after_response_ext.flush])
        except Exception:
            print_exc()
            return iterator

The source code can be found here

Dmitrii
  • 877
  • 1
  • 6
  • 12
  • This records callbacks on the global middleware object and then pops them after one request. This suggests the callbacks are meant to be registered per-request, which would make sense since the callbacks need to be closures bringing their context with them, but then it's not thread-safe. – Kiran Jonnalagadda Jul 24 '20 at 20:28
  • I try, but it doesen't work for Flask-SQLAlchemy. Do you have any solutions – Linh Nguyễn Ngọc Jun 04 '21 at 03:44
  • No yet for SQL, will try on weekends – Dmitrii Jun 05 '21 at 00:48
0

The signal request_finished receives a Response instance as parameter. Any after-processing can be done by connecting to that signal.

From https://flask-doc.readthedocs.io/en/latest/signals.html:

def log_response(sender, response, **extra):
    sender.logger.debug('Request context is about to close down.  '
                        'Response: %s', response)

from flask import request_finished
request_finished.connect(log_response, app)

Obs: In case of error, the signal got_request_exception can be used instead.

augustomen
  • 8,977
  • 3
  • 43
  • 63
  • from flask docs "This signal is sent right before the response is sent to the client. It is passed the response to be sent named response." I tested it and yea, unfortuantely, response will also be only sent after post processing done if using this way – Jake May 26 '20 at 02:59
0

After read many topics. I found the solution for me, if use Blueprint, it is worked for python 3.8 and SQLAlchemy

init.py

from flask import Flask
from flask_sqlalchemy import SQLAlchemy
from flask_login import LoginManager
import dir
import time
from flask_mail import Mail
from flask_cors import CORS
import flask_excel as excel
    # init SQLAlchemy so we can use it later in our models
dbb = SQLAlchemy()
def create_app():
     app = Flask(__name__)
     from .bp_route_1 import auth as bp_route_1_blueprint
     app.register_blueprint(bp_route_1_blueprint)
     CORS(app)
     return app

bp_route_1.py

from flask import Blueprint, request, redirect, Response, url_for, abort, flash, render_template, \
    copy_current_request_context
from . import dbb 
from .models import #Import Models
from threading import Thread
bp_route_1 = Blueprint('bp_route_1', __name__)

@bp_route_1.route('/wehooks', methods=['POST'])
def route_1_wehooks_post():
    @copy_current_request_context #to copy request
    def foo_main():
        # insert your code here
        do_long_time_webhook(request)
    Thread(target=foo_main).start()
    print("do Webhook by Thread")
    return Response(status=200)
def do_long_time_webhook(request):
    try:
        data = request.get_data()
        print(data)
        #do long tim function for webhook data

    except Exception as e:
        print('Dont do webhook', e)
-1

You can use this code i have tried it.It works.

this code will print the string "message". after the 3 second ,from the scheduling time. You can change the time your self according to you requirement.

import time, traceback
import threading

def every(delay,message, task):
  next_time = time.time() + delay
  time.sleep(max(0, next_time - time.time()))
  task(message)

def foo(message):
  print(message+"  :foo", time.time())



def main(message):
    threading.Thread(target=lambda: every(3,message, foo)).start()

main("message")
Muhammad Usman
  • 1,220
  • 13
  • 22
  • 1
    Unfortunately, using a thread works for the simple case of printing a message, but will cause problems when accessing other variables and context. – Brandon Wang Aug 03 '18 at 14:45