Preserve request context in the face of new requests #410

dplepage opened this Issue Feb 24, 2012 · 7 comments


None yet

3 participants


RequestContext.push pops and discards the top of the context stack if the top is preserved. Consequently, if you hit an exception in debug mode and drop into the debugger, but then make another request of the server, your debugger can no longer access the preserved context from the exception.

This is particularly a problem in Google Chrome, which follows each request with a request for "/favicon.ico". Any exception in debug mode will leave a preserved context on the stack, but will then immediately discard it when the favicon request arrives.

This was briefly discussed on IRC:
Mitsuhiko's suggested workaround for Chrome users hitting the favicon bug is "add a wsgi middleware that intercepts /favicon.ico before the it bubbles to the app".


@mitsuhiko points out in IRC that the workaround is in the Werkzeug HEAD at pallets/werkzeug@00c65aa.

This solves the chrome-specific problem of favicon clobbering the context; it would still be nice if, in general, a preserved context could survive additional requests.


@mitsuhiko explained this in #pocoo. Currently, the werkzeug debugger keeps all contexts alive, but in Flask, only one is kept. On an error, the request context is preserved; the next request invalidates it. To the question of: "Should Flask keep multiple error contexts?", the favicon workaround (once released) removes the primary motivation to do so.

As @mitsuhiko puts it [reformatted from IRC], "I never had the situation where I needed to debug two separate bugs at once through the debugger. Typically if I get the debugger, I either triggered it by hand or it was something I did not expect, and in order to change the situation, I needed to reload the whole interpreter anyways."

@dplepage, do you have a use case to support, keeping in mind that the code reloader will remove all error contexts?


Linking #405, but this issue (#410) requests context preservation more generally. Current status: looking for use cases to support context preservation, given werkzeug now has a fix for the favicon issue (#405).

I have had this come up in other situations, but it's rare. The two use cases I can recall are:

  1. I am in the debugger on some part of the site when a coworker asks me a question about an unrelated part. I load this other part in a separate tab, but doing so erases my context in the debugging tab.

  2. I have multiple tabs open with different parts of the site, and while I attempt to debug something in one tab the loaded page in another makes some timed AJAX call, erasing my debugging context.

A third use case, which I have not personally encountered, is that of two or more people working together on the same running Flask instance - any request by any person invalidates error contexts for anyone else who's debugging.

That said, all three of these cases are rare, and usually I don't do very much in a debug session, so I don't lose much if I have to reload it to get a new context.

DasIch commented Jul 27, 2014

Closing this because fixing this is not worth the effort. It requires changing the stack based design, it requires the ability to move request contexts between threads and how all this would work in combination with the application context is also not trivial to figure out.

@DasIch DasIch closed this Jul 27, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment