Optional copy_current_request_context

[tandu]

Can you add an option to config for optional copy_current_request_context? I don't need this context in my functions. I'm running a background thread on server launch where request context doesn't exist yet. So it throws an error and I don't see any other way to fix this.
i.e.
change this:

fn = copy_current_request_context(fn)

to something like this:

if current_app.config[self.EXECUTOR_PUSH_REQUEST_CONTEXT]:
    fn = copy_current_request_context(fn)

[dchevell]

I'm running a background thread on server launch where request context doesn't exist yet.

Does the app context exist at this stage - i.e. the Flask app has been initialised? Just curious to ensure I know at what stage you're trying to launch the task, if you have a simple example

[tandu]

from flask import Flask, make_response, request
from flask_executor import Executor


executor = Executor()


def create_app():
    app = Flask(__name__)

    app.config['EXECUTOR_TYPE'] = 'thread'
    app.config['EXECUTOR_PROPAGATE_EXCEPTIONS'] = True

    executor.init_app(app)

    with app.app_context():
        process_queue() # !!! flask_executor needs request_context, it doesn't exist on launch

    return app

[tandu]

def process_queue():
    future = process_task.submit(task)
    future.add_done_callback(task_processed(task))


@executor.job
def process_task():
    time.sleep(5)

[tandu]

I cloned the project, made the change that I needed and it works. You can look at my commit here:
https://github.com/tandu/flask-executor

[tandu]

Hi @dchevell - any updates on this?

[joao-aveiro]

Bump. This has proven to be quite important when building custom Flask CLIs, since there is no request context in that case (though the app context is fully functional). I have followed @tandu 's implementation quite closely, and it seems to be working for my application (at least when using threads; with processes some other problems arise). @dchevell I think adding this functionality would be a good (and easy) improvement, and it would not break existing deployments, granted the defaults are set up appropriately.