-
-
Notifications
You must be signed in to change notification settings - Fork 899
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
session.remove called too early when there are stacked application contexts #508
Comments
out of curiosity, why do you have multiple instances of the same app's context on the stack? |
Good question :) In my background jobs, before using Flask-SQLAlchemy, I didn't need application context for all tasks, so I was explicitly pushing it for a few of the tasks that did need it (to use Flask-Mail). After switching to Flask-SQLAlchemy, I changed the background jobs base class to push application context before running the tasks as it was always required now. This resulted in the application context being pushed twice and exposing this issue. I can't imagine a real world scenario when this might happen, but because it does expose some unexpected behavior, I thought it's worth reporting. |
#1087 changes the session scope to use the current app context instead of the thread. If there are different contexts pushed, there is a different session for each context. |
Currently flask-sqlalchemy will call
session.remove()
whenapp.teardown_appcontext
is called. Because application contexts can be stacked, it means that we will remove the session when the inner most application context is popped, while there still might be other active contexts.Aren't sessions supposed to be scoped per application context?
Here's an example to show the issue:
The text was updated successfully, but these errors were encountered: