Debugger should show the right request object.
Paste a minimal example that causes the problem.from flask import Flask, request
app = Flask(__name__)
@app.route('/')
def hello_world():
print(request)
x = y
return 'Hello, World!'
if __name__ == "__main__":
app.run(debug=True)
We're seeing some honestly kind of dumbfounding behavior that makes no sense to us. I'm not a novice when it comes to troubleshooting things, but this one really baffles me because I'm basically certain I'm not doing anything weird.
Debugger doesn't show the right "request" object often. See https://pasteboard.co/HqFNzwq.png for a screenshot of a case where the browser's URL bar shows the right thing, printing the request object shows the right thing in console logs, but using the debugger does not.
The request object is sometimes unbound, sometimes right, and seemingly often "off by 1" based on history.
So far, we can only seem to reproduce this on Linux, using Chrome and Firefox (edit: at first we thought it wasn't happening with Firefox but we found a repro with Firefox on Ubuntu 16.04 ). It doesn't seem to be happening from a Mac OS chrome client.
I ran git bisect, and according to it, this is the first "bad" commit:
https://github.com/pallets/flask/commit/3738f7ff99661fa0319ebe2d8228ad8c479fb46a
This commit turned on threading by default. So I tried turning off threading, and indeed the bug seems to go away.
I am running Flask on Ubuntu 16.04.3 inside Vagrant VM hosted on a Mac (High Sierra). I cannot reproduce the bug running natively on the Mac.
If threading is indeed the deciding factor, would it be reasonable for the documentation to stipulate that threading should be turned off in debug mode, or have threading default to false when in debug mode?
I'd rather try to fix the debugger.
The debugger is actually good with multiple threads, it's Flask's request object that's not. When there's an error, a single context is preserved on the stack, but this can get out of sync with multiple threads.
Most helpful comment
The debugger is actually good with multiple threads, it's Flask's
requestobject that's not. When there's an error, a single context is preserved on the stack, but this can get out of sync with multiple threads.