Errors can occur in Chrome.prepare_request() during Request.send_error()

[ebray]

There are some cases where, when an error occurs sne send_error() is being called, that Chrome.prepare_request() can error out too, leaving the client with nothing but a traceback.

In particular, this occurs during some database errors, such as good ol' 'database is locked'. The problem comes from the fact that in prepare_request() the navigation_contributors are looped through, and get_navigation_items() is called for each of them. However, some navigation_contributors access the database, for example, for permission lookups. This can lead to another 'database is locked'.

I think that if the handler argument to prepare_request() is None, this step should be skipped. Or only certain navigation items should be displayed. For example, in my implementation, all the mainnav items are removed from the page, as are all the metanav items except for those added by the LoginModule. Just another possibility. At any rate, if handler is None, I can't imagine any other reason to generate the navigation items.

Should also make sure that before calling req.send_error(), req.callbacks['chrome'] is in fact set to chrome.prepare_request() and not a partial function.

As an aside, the motivation for this is a plugin I wrote called TracFailWhale that displays a more user-friendly error message when there are database availability issues. It includes some ugly hacks to get around this problem, which I would prefer to avoid. And I think my proposed solution makes sense.

[Christian Boos]

I wonder if it wouldn't be possible to first try to get the navigation items, and if that fails, proceed anyway. If you don't have any navigation item, how do you resume working after an error happened?

See also #8468 for another attempt to reduce the occurrence of the good ol' one ;-)

[anonymous]

Replying to cboos:

If you don't have any navigation item, how do you resume working after an error happened?

Well, in the case of my failwhale plugin, it tries refreshing the page anyways, at which point it should be possible to resume work. But you have a point—*some* form of navigation might be desired.

[Remy Blank]

This shouldn't block 0.12.

[Christian Boos]

I have a patch for this, please review.

[Christian Boos]

Make preparation of request more robust w.r.t. failures in navigation contributors. Currently on 0.11-stable r8704.

[Christian Boos]

Get away with the FakeReq class in the Chrome.prepare_request Request callback. Applies on top of more-robust-error-reporting.patch​.

[Christian Boos]

(the patches also apply on trunk)

[Christian Boos]

Patches above applied on trunk, in r8760 and r8761.

[Christian Boos]

Note that errors other than TracError still go through. I'll try to improve that.

[Christian Boos]

More robust error rendering implemented in [8785].