after_request behavior regarding exceptions #174

mitsuhiko opened this Issue Feb 17, 2011 · 5 comments

4 participants

The Pallets Projects member

after_request is not executed if an exception happens in debug mode. This is annoying for databases because it requires that you restart the server to tear down the connection. Sometimes that's what you want, otherwise not. The original intention was that you want to continue having the transaction in the interactive debugger.

Generally however we need a separate decorator that always executes after request, even if an exception happened. Signals are one option, if that is what we want we should document it better. I would prefer a separate decorator however.

Related feedback issues:


The current behavior leaves uncommitted transactions around, which can then be committed by subsequent requests. That's really confusing and unexpected behavior, at least for me. On the other hand, I do see the value in keeping the transaction around for the debugger.

I'm not too familiar with the deep internals, so this might not make any sense, but would it be possible to remove the thread in which the exception occurred from the thread pool (and replace it with a new one), but keep that thread alive to run the debugger in? That way, you don't have to execute the after_request functions and kill the DB transaction, but the transaction won't randomly pop up in subsequent requests.


brainsik and I are working on this.


fixed in SHA: 04e70bd


Please close.

The Pallets Projects member


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