After updating to 2.8.8 from 2.8.5, started seeing a bug that occurs on 2.8.7 as well
See original GitHub issueHi Charles and team,
First, many thanks for creating an AMAZING ORM – we depend on it and we love its simplicity.
So the weird bug is, we see a
OperationalError('Connection already open')
In our boilerplate Flask connection open/close code (copied from the docs), and it happens only on the first time our server comes up running on the google app engine development server.
# set up DB handling
@app.before_request
def connect_db():
our_db.connect() # this raises an operational error only on the first request
@app.teardown_request
def close_db(exc):
if not our_db.is_closed():
our_db.close()
Thing is, I can move back to 2.8.5 and everything works normally – no OperationalError is raised. Though we looked at the commits between .5 and .8 and didn’t see anything unusual. Your insight is appreciated! Thank you in advance, and again, we love Peewee!!! (Our temporary fix is sticking with 2.8.5)
-savraj
Issue Analytics
- State:
- Created 7 years ago
- Comments:6 (2 by maintainers)
Top Results From Across the Web
RHEL 7 : Ansible security and bug fix update (2.8.8) (Moderate ...
The remote Redhat Enterprise Linux 7 host has a package installed that is affected by multiple vulnerabilities as referenced in the RHSA-2020:0216 advisory....
Read more >Access Server Release Notes - OpenVPN
Fixed a bug when upgrading from Access Server version 2.6.1 to 2.9.5 and newer. Fixed a bug when upgrading with a 9+ year...
Read more >Pivotal Operations Manager v2.8 Release Notes
[Bug Fix] Fixes issue where some upgraded Ops Managers do not have the UAA Restricted Client Secret property set properly. This property is...
Read more >ERROR 999999 Something unexpected caused the tool to fail
In the Catalog pane in ArcGIS Pro, right-click the enterprise geodatabase connection, and click Geodatabase Connection Properties.
Read more >Rasa Open Source Change Log
#11724: Update migration guide and form docs with prescriptive ... in MainThread when starting Rasa Open Source for Rasa X with JWT secrets....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I bumped into this too. The commit that causes this is 9e76c999868197a4911fa2fa457c50ab42431ff1, which came about because of #1108.
The pull request explains why the commit is necessary and how you can solve your problem, but in short use
our_db.get_conn()
instead ofour_db.connect()
.If this is a permanent solution then the docs should probably be updated (especially the Adding Request Hooks section), but I’ll leave that up to @coleifer to decide.
@flother – thanks, by the way, for providing the details on the commit and a workaround.
The change prevents connections from being opened and then subsequently not closed because the reference to them was overwritten with a 2nd connection.
The OperationalError is clue-ing you in to a spot in your code where you’ve already got an open connection for the given thread and are trying to open a new one on top of it. Like I said – check for database accesses at module scope or during application startup, those are likely to be the culprits.
As for using
get_conn()
in the hooks, I still think it is advisable to useconnect()
, because in most applications an exception would only be raised because the developer had forgotten to close one somewhere…which seems like a bug.