Document the fact that a DB connection can be closed mid-request when a HTTP client disconnects prematurely

[Rich]

I've described and diagnosed an issue that has caused me headaches for some weeks here:

​https://forum.djangoproject.com/t/db-connection-closed-by-uwsgi-in-the-middle-of-handling-a-request/9875

This took a lot of effort to investigate, and I'd like to avoid others having to do the same.

I think the official doc needs to explain that a HTTP response can be closed DURING the handling of a request - when this happens, seemingly random django.db.utils.InterfaceErrors can be thrown.

These are very difficult to debug because of the way the HttpResponse.close() code has run asynchronously and invisibly.

It may be that the Django code could also benefit from some changes...the HTTP client closing the connection early is after all within the scope of 'normal' behaviour - right now quite what happens depends on whether a transaction is in effect or not, as well as other, essentially arbitrary settings. Some sort of normalised behaviour would be great, but I don't see how to implement it without setting some sort of global flag on close which is regularly checked somewhere...

[Mariusz Felisiak]

I think the official doc needs to explain that a HTTP response can be closed DURING the handling of a request - when this happens, seemingly random django.db.utils.InterfaceErrors can be thrown.

HttpResponse.close() is called at the end of a request by the WSGI server. I'm not sure what is calling close() in your case but I don't see why and where Django is at fault. Handling of an HTTP request can be interrupted in many ways and Django doesn't do anything unusual in this matter. IMO, Django docs are not the best place to explain this.