Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

DEBUG reloader is too agressive #549

rbucker opened this Issue Jul 16, 2012 · 11 comments


None yet
4 participants

rbucker commented Jul 16, 2012

My webapp is a single file app. It's also 37K now. I'm editing the file using BBedit via the built-in SFTP feature in BBedit. In the last 24hours I've been experiencing latency between my desktop and the remote system. When I "save" my PY file and flask detects the change it immediately tried to reload it. When I was using vim locally it worked great. Now that I'm going remote... (1) flask tried to reload the py file but it's only partially there.

(yes, it would be better if BBedit save the file to a tmp file and then renamed it, however, I do not claim to know the motivation for the current methodology)

Anyway, give than I have no idea what the flask issues are... I'd recommend a token at the end of the file that could be detected to make sure that the entire file is ready before loading it.

Also, (2) the reloader seems to crash quietly each time.


untitaker commented Nov 13, 2012

The reloader wouldn't get a chance to handle the crash, since a partial Python file probably results in a syntax error.

I don't think this is an issue Flask (or any of its dependencies) should handle, i think BBEdit should.


soulseekah commented Nov 13, 2012

currently we always use the stat loop reloader for the simple reason
that the inotify one does not respond to added files properly. Also
it's quite buggy and the API is a mess.

But this is Werkzeug territory, no? https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/serving.py#L489

@rbucker881 did you ever find a way around the issue? Did you disable it perhaps? Or something else? Any thoughts to share?

rbucker commented Dec 7, 2012

the flask team has not responded that I know. @untitaker responded but I do not understand... to be more precise it appears that flask's restart is leading edge triggered instead of trailing edge. It also does not consider when multiple files in the project dependency are updated at the same time.


untitaker commented Dec 7, 2012

Are you using app.run in production?

rbucker commented Dec 7, 2012

I'm not referring to production. This is a dev issue.


untitaker commented Dec 7, 2012

What is your dev server doing on a remote system?


untitaker commented Dec 7, 2012

It would be a quickfix to use

while true; do ./testserver.py; sleep 2; done

which is easy enough, since it will restart the whole interpreter every time the server crashes.

rbucker commented Dec 7, 2012

that's not a preferred solution but it'll work.

@rbucker rbucker closed this Dec 7, 2012

techniq commented Dec 7, 2012

Not sure if this would help with your specific case, but I use Flask-Failsafe (http://pypi.python.org/pypi/Flask-Failsafe/) extension to safeguard against some syntax errors from killing the dev server.

rbucker commented Dec 7, 2012

That looks like an interesting solution. Very similar to that other solution but quite possibly better. In that other solution a proper syntax error will cause the application to load and crash and load and crash ... until it's fixed. Failsafe suggests that it'll trap the exception and give you a chance to repair it without generating too much heat. which is good if you actually insert an error but "could" be a little greedy when the issue is latency when uploading or saving new code. I'd have to check to see if it's leading or trailing edge triggered.

techniq commented Dec 7, 2012

Note, I still find a way to crash even with the extension wrapping my create_app, but it greatly reduces it happening. I get a little trigger happy with Command+S :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment