-
-
Notifications
You must be signed in to change notification settings - Fork 16k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failing to start (due to port unavailable) cannot be directly determined by the current python api #5471
Comments
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:
|
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 |
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. |
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:
example code:
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:
Mildly related on the same theme of api startup and shutdown:
https://stackoverflow.com/questions/72824420/how-to-shutdown-flask-server
The text was updated successfully, but these errors were encountered: