2👍
I’ve figured this out. It’s pretty wild, but makes sense.
Fundamentally, the HTTP client is disconnecting early, while the request is still being processed.
uWSGI must be handling the disconnect in a separate thread than the request handler – this is fine because it acquires the Python GIL before calling into Python.
A totally unexpected (to me anyways!) consequence of this is that the close call is simply injected into the request handler’s call stack – the request handler code is running, then suddenly execution switches to the HttpResponse close code. I observed this in stack traces during debugging – see this question for the details.
As part of Django’s end-of-request handling, the DB connection may be closed if Django thinks it’s broken – this happens because an unexpected transaction is in effect – one started by my own code above the injected HttpResponse.close() call.
When the HttpReponse.close() call finishes running and the interpreter returns to my code, the transaction error is raised because the DB connection has been closed.
So really I think this is all as it should be, more or less. It would be nice to have a more specific ‘premature close’ error rather than the more generic "connection already closed" error, but I’m not sure how you would neatly construct such a thing.