Code

Opened 3 years ago

Closed 3 years ago

#14717 closed (wontfix)

Connection error not handled

Reported by: nijel Owned by: nobody
Component: Uncategorized Version: 1.2
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

When there is connection error in MySQL backend, the exception is not handled and MySQL exception is thrown out of django. I think there should be try...except block around Database.connect and handle MySQLdb.OperationalError and handled somehow.

The exception looks like:

  File "/usr/lib/python2.6/site-packages/django/db/backends/mysql/base.py", line 297, in _cursor
    self.connection = Database.connect(**kwargs)

  File "/usr/lib64/python2.6/site-packages/MySQLdb/__init__.py", line 81, in Connect
    return Connection(*args, **kwargs)

  File "/usr/lib64/python2.6/site-packages/MySQLdb/connections.py", line 187, in __init__
    super(Connection, self).__init__(*args, **kwargs2)

OperationalError: (2003, "Can't connect to MySQL server on '127.0.0.1' (111)")

Attachments (0)

Change History (1)

comment:1 Changed 3 years ago by kmtracey

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

Handled how? The database being unreachable is a catastrophic error -- in general there is no reasonable way to recover from that. The effect of allowing the exception to propagate will be for a server error page to be returned to whatever browser generated the current request, and an error email to be sent to the admins containing the traceback (assuming DEBUG is off, with DEBUG on a debug error page will get returned to the the browser). That seems to me to be about the best that can be done when current circumstances make it impossible to correctly serve a request -- the end user gets told that something is currently wrong with the site, and the admins get the details of what it is.

(Also as a side note: why would MySQL alone be handled any differently from the other database backends here? If we were to change how "database unreachable" is handled, I would think we would want to maintain consistency among them and not make any one behave differently for this case.)

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.