Keep code running after response has been sent. (To respond with HTTP requests to other servers)
PokerBuddyAI opened this issue · 6 comments
Ability to send a response but continue execution.
An example of this problem is a backend Flask server which receives requests from another backend server, and returns one or more responses at different points in time. One such example is Telegram API.
https://core.telegram.org/bots/faq#how-can-i-make-requests-in-response-to-updates
While it is possible to simply send data back as an HTTP response, it is sometimes desirable to close the HTTP connection with a 200 to acknowledge the message has been received, and reopen a new connection for each response.
Here are some scenarios where this technique might be useful:
- Multiple messages are sent in a progressively more detailed nature, to ensure that errors in complex responses don't compromise simple responses. For example Response("Hello") Response ("Error") Response("Error 194:blablabla")
- Separating messages carry a semantic meaning. For example: Response("Ok so here's the plan\n We leave at 9 am \n ...") != Response("Ok so here's the plan") Response("We leave at 9 am") Response("...")
- Responses may be scheduled for the future, well after the http connection closes by timeout.
Can we solve this without a builtin? Yeah sure, we can use threading or multiprocessing or libraries like celery.
I think that the ideal solution is to integrate the multi threading into existing flask multithreading (Main server loop), and ideally integrating it into production one worker process per hardware core configurations to avoid both GIL issues and one process per request overheads.
That's now how HTTP works. There's one response (status code / headers). Of course you can send/stream whatever you want in the body, but it doesn't sound like you want to do that...
Thanks for the response Adrian.
I understand that each Request can only have one response. Not sure what would even happen if two responses are sent in response to one request, don't care.
What this thread is about is, recognizing that limitation, many server-to-server servers that need to send more than one response per request, effectively send nothing on the corresponding http response, but send new HTTP requests altogether, in all likelihood the responses of these second requests is ignored as well.
This image from the docs linked above should clarify
As you can see the traditional approach is diagrammed in 2. But the approach I'm referring to is diagrammed in 1. This allows multiple replies (Outgoing Request) per incoming request to the Flask server.
This may be out of scope for flask, I will take a look into using Werkzeug directly, which may have a more native approach towards this, that may not even need threading, in essence we just want to (send a response/do stuff) without closing the inbound-request-thread.
It's just that in Flask sending an HTTP response and closing the request-thread seem to be tightly coupled. Perhaps there is a way and I'm just ignorant of it. I typically send an http response returning from a function marked as a route, maybe there's something like flask.respond(200,"Hello")
If not, that would be the ideal API flask.respond(status_code,body), function may be called respondAndContinue if you want to avoid confusion.
You're looking for a background task queue. https://flask.palletsprojects.com/en/3.0.x/patterns/celery/
I suppose one could import thousands of lines of code and add yet another layer of scheduling abstraction.
But I'd rather remove than add
This is a good use case for Quart and the background tasks.