Comment 5 for bug 360846

The fix isn't working.

We do have a better understanding of what is happening. https://pastebin.canonical.com/17341/ shows a bunch of InterfaceError OOPS that happens. We see that one stretch of OOPS begins at OOPS-I2432. If we look at the previous OOPS-I2431, we see that an OperationalError was raised during the call to set_statement_timeout. Because that method doesn't use the _check_disconnect wrapper, the error is uncaught and leaves the connection in a disconnected state.

The following request gets an InterfaceError because of this. The suggested fix isn't enough because is_disconnection_error() is only called when the error is a subclass of DatabaseError. This isn't the case for InterfaceError.

We have no idea why the initial OperationError is happening. What is weird is that the client reports that the server disconnects it, but on the server, we see that it closes the client socket two minutes after the error. See https://pastebin.canonical.com/17342/ (to compare the timestamps).