Last modified: 2012-12-19 17:03:33 UTC
Created attachment 10659 [details] Screenshot of JavaScript errors produced by action=raw when viewing a regular page When the database is unavailable, action=edit and other actions that use the master database produce a "Database error" page with the famous text: > Sorry! This site is experiencing technical difficulties. > [search] etc. However for for action=raw&ctype=text/javascript this shouldn't happen. Just like it has a special casing to output /* Empty */ in certain cases, it should output a comment instead of an HTML error page so that there are no javascript errors like this. Aside from the broader issue, specifically in case of a db-master failure one could consider to use the slave DB for this, but that may not be a good idea since action=raw should always output the latest content and should be reliable to use as input for editing (which is what it was originally intended for).
It correctly loaded for me during the outage. Checked with the url http://commons.wikimedia.org/w/index.php?title=MediaWiki:CollapsibleTemplates.js&action=raw&ctype=text/javascript copied from your screenshot above.
No, at the time I posted this bug report, although the outage was still current, wgReadOnly was already activated and thus it was read from a slave. When the db error was actively taking the entire page on action=edit (a few minutes earlier), action=raw was also affected (as can be seen in the console in the screenshot). Try reproducing locally. Mess with the db config and try loading something from action=raw.
I see. The problem is that when we get a hard db failure (such as a connection error) we bail out with that hardcoded message and die. We should try not to add much code there. We may be able to abuse the fact that /* DB error */ is both valid js and css.
If an HTTP error code is returned, as far as I know it shouldn't attempt to execute the script etc. Is the problem that HTML is being returned, or that the HTML is labeled as HTTP 200 OK?
It *is* reporting a 200 Ok. I think we should make it a 500. Patch provided at https://gerrit.wikimedia.org/r/9521
(In reply to comment #3) > I see. The problem is that when we get a hard db failure (such as a connection > error) we bail out with that hardcoded message and die. We should try not to > add much code there. > > We may be able to abuse the fact that /* DB error */ is both valid js and css. This is also done with 404, where ctype=text/css;text/javascript responds with /* Empty */.
