Thank you for the hint, we did pin whitenoise version to 5.3.0, and it indeed solved our random connection errors.
So, there appears to be a relation; however, it is tricky (in our case) to pin down to a certain version/commit/functionality.
I also posted this as an issue in whitenoise repo:
(the only thing - I am struggling to reproduce it outside our production instance)
Just wanted to share that I had this error show up for me today for the first time. I am using whitenoise==6.6.0 It is a bit strange though as I have had this project running for many months now and never experienced any problems before. even now it seems to be only 2 or 3 requests in a thousand
Hello everyone, I’m glad I’m finding this thread, as we are starting to seriously lose our mind here, experiencing the same random issue every couple of requests.
What we have narrowed it down to is: we only see this when running our django app from a Docker container (in either Azure App Service or Azure Container App: the issue happens in both) but never when running the same app on a regular Linux VM without using Docker (just plain gunicorn on Ubuntu server).
Our setup:
Python 3.12
Django 4.2.20
gunicorn 22.0.0
psycopg 3.2.4
Postgres 15 or 16 (tried both) (managed Azure Database for Postgresql Flexible Server)
Both using pgbouncer and without pgbouncer enabled
Now indeed, one difference for us running in a Docker container is that we use django-whitenoise in this situation, and NOT when running on pure Linux VM (where we let nginx serve the assets).
So I am very interested in that clue and will experiment with and without whitenoise.
It is rather hard to debug this due to the very random occurrences of the issue: can happen in any request on any page (including django admin interface) and at any point in the traceback…
If anyone has had a more precise resolution, please share any update you have here!
I confirm that upgrading to whitenoise >= 6.8.0 seems to fix this issue for us. It looks like this very thread here is what alerted them of the issue and got them to fix it: Changelog - WhiteNoise 6.9.0 documentation
We need to monitor our app for a longer period of time after upgrading whitenoise to be more confident this is completely resolved for us.
Just wanted to say a big thank you for this thread. It ended up helping us solve a problem we had been chasing for more than 4 weeks. Our setup was Django 5.2.8, gunicorn 22.0.0, and first psycopg 3.3.3, later psycopg2 2.9.11.
Our symptoms were very similar: seemingly random PostgreSQL connection drops during normal Django requests, on unrelated pages and code paths. Firstly the incidence was relatively low like 0.1%, but for past couple of weeks it went considerable higher. In our case the errors showed up in couple of different places, mostly on pages that were doing DB writes and (not often though) ordinary read-only pages. Nothing about the affected endpoints suggested a single application bug.
What made this especially confusing is that while we were on psycopg3, the failures were mostly surfacing as:
OperationalError: the connection is closed
Only after we switched back to psycopg2 did we start seeing the much clearer: InterfaceError: connection already closed.
That very wording is what finally led us here. Before finding this thread, we went through a long list of false leads:
• server restart correlation
• stale connections / CONN_MAX_AGE, CONN_HEALTH_CHECKS
• direct DB vs pooler
• follower / fresh database
• Django, Python versions
None of those explained the pattern well.
The actual culprit for us also turned out to be WhiteNoise. We were on whitenoise==6.6.0. After upgrading to whitenoise==6.12.0, the errors disappeared. Like Bastien, this was the last thing we would have expected to be related to database connections, which is exactly why this thread was so valuable.
So thank you for documenting the experience here. Without the detail shared in this thread, especially the WhiteNoise angle, I think we would still be looking in the wrong place.
Hopefully this gives one more data point for anyone else landing here with “random” Postgres connection drops.