pallets / flask

The Python micro framework for building web applications.

Home Page:https://flask.palletsprojects.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Failing to start (due to port unavailable) cannot be directly determined by the current python api

matanox opened this issue · comments

I believe that failing to start (due to the designated port being unavailable) cannot be directly determined by the current python api, if not mistaken.

When the port specified for startup is taken, a python code starting the server with Werkzeug cannot know if startup has failed, since no exception is raised, and no api is there to check on its status, while the following is written to stderr:

Address already in use
Port 5000 is in use by another program. Either identify and stop that program, or start the server with a different port.

example code:

from flask import Flask
from werkzeug.serving import run_simple

app = Flask(__name__)

try:
    run_simple('127.0.0.1', 5000, app)  
except Exception as e:
    start_success = False

Even though traditionally most web servers frameworks did not touch up their startup and shutdown usability from code to those levels, I think it would be implied to provide the caller with this basic level of transparency being robustly enabled for them. Apologies in advance if I've missed any obvious way.

Environment:

  • Python version: 3.10.13
  • Flask version: 3.0.3
  • Platform: Ubuntu 22.04

Mildly related on the same theme of api startup and shutdown:

https://stackoverflow.com/questions/72824420/how-to-shutdown-flask-server

Complete code reproducing the context, which would hopefully also become a skeleton (or inspiration) for a flaks test, after an api transparency into failure to use the specified server port has been very hopefully incorporated in flask:

from flask import Flask
from werkzeug.serving import run_simple
from multiprocessing import Process

app = Flask(__name__)

def start():
    print('starting a flask server')
    try:
        started = run_simple('127.0.0.1', 5000, app)
    except Exception as e:
        print(f'the flask web server crashed with an exception:\n{e}\n')
    else:
        # of course we will never get here unless the server shut down without throwing
        print(f'the flask web server finished with return value {started}')


if __name__ == '__main__':

    flask_process = Process(target=start, daemon=True)
    flask_process.start()

    start()

Note that, the messages about the port being unavailable come out on stderr, same as success messages such as the following type, and hence this leaves no deterministic way for the code starting the server to resolve the status of the server, other than parsing stderr:

127.0.0.1 - - [28/Apr/2024 13:31:24] "GET / HTTP/1.1" 200 -

Not sure what you are trying to do, but keep in mind that this server is ONLY meant for development purposes, NOT for anything else. So if you want to run a flask app embedded in some other application for whatever reason, using run_simple is not what you should do.

Makes sense. My scenario is borderline in that regard. Will I have that kind of api-laden way of knowing the status of the server when using a non Werkzeug WSGI component?

Okay, I understand then that no underlying supported WSGI server component can be controlled (start and stop) robustly from Flask code then, and that that is not planned either.