Broken Error Reporting?

[dave@…]

The following comes up as the entire literal contents of the page I'm viewing. It seems to me to be broken in several ways:

1. It's not valid HTML
2. Trac's nice built-in traceback display is bypassed.
3. It appears to be generating an error while reporting an error. In this case the original error is lost and the system tells the user almost nothing she needs to know in order to debug the problem.

Is that really the intended behavior?

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg/trac/web/api.py", line 339, in send_error
    'text/html')
  File "/usr/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg/trac/web/chrome.py", line 702, in render_template
    if not req.session or not int(req.session.get('accesskeys', 0)):
  File "/usr/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg/trac/web/api.py", line 169, in __getattr__
    value = self.callbacks[name](self)
  File "/usr/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg/trac/web/main.py", line 257, in _get_session
    return Session(self.env, req)
  File "/usr/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg/trac/web/session.py", line 150, in __init__
    self.get_session(req.authname, authenticated=True)
  File "/usr/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg/trac/web/session.py", line 164, in get_session
    super(Session, self).get_session(sid, authenticated)
  File "/usr/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg/trac/web/session.py", line 56, in get_session
    (sid, int(authenticated)))
  File "/usr/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg/trac/db/util.py", line 50, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
  File "/usr/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg/trac/db/util.py", line 50, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
ProgrammingError: current transaction is aborted, commands ignored until end of transaction block

[Noah Kantrowitz]

Check the log file for the original error. I would put a decent wager this is coming from a plugin's bad SQL.

[dave@…]

Yes of course it is a plugin's bad SQL, and it does show up in the log. I'm not asking for help debugging the thing that caused the error; I'm asking that Trac improve its handling and reporting of such problems.

[Remy Blank]

Replying to dave@…:

2. Trac's nice built-in traceback display is bypassed.

It's not bypassed, the error happens while rendering the nice built-in traceback.

3. It appears to be generating an error while reporting an error. In this case the original error is lost and the system tells the user almost nothing she needs to know in order to debug the problem.

Correct, this is not very useful.

Is that really the intended behavior?

Obviously not, but it's a catch-22 situation. What we could probably do to reduce the likelihood of this happening is minimize the code path in Request.send_error(). In this particular case, not retrieve data from the session store.

[Remy Blank]

Refocusing.