Last modified: 2009-07-24 14:13:10 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T20824, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18824 - customised version of dberrortext not displayed
customised version of dberrortext not displayed
Status: RESOLVED DUPLICATE of bug 398
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
1.15.x
All All
: Normal minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-17 21:55 UTC by Happy-melon
Modified: 2009-07-24 14:13 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Happy-melon 2009-05-17 21:55:11 UTC
when a dberror occurs on enwiki (almost invariably the "lock wait timeout exceeded" error), the message that displays is the default english version; despite the fact that the message has been customised on enwiki.  The customised version is not overriding the default message.
Comment 1 Niklas Laxström 2009-05-17 22:09:28 UTC
I wouldn't be surprised that customised version cannot be fetched from database when there is database error. On the other hand aren't these stored memory?
Comment 2 Happy-melon 2009-05-18 07:34:09 UTC
Well the lock-wait-timeout has got nothing to do with the slaves, it's just a traffic jam on the master. It should still be possible to read stuff if necessary: it manages to render the rest of the skin ok.  Of course, that might not be the case on systems with a single database, but even then, as you say, the message should be memcached.  
Comment 3 Brion Vibber 2009-05-18 18:02:29 UTC
I'm pretty sure we deliberately don't use the site-customized messages in the DB error since by definition if our DB access is broken it may not be safe to pull from the DB. You don't necessarily know what the problem was or what further attempts to access the backend might cause. Probably not worth the effort of poking at it, but we can LATER it for prettification.
Comment 4 Happy-melon 2009-07-24 14:13:10 UTC

*** This bug has been marked as a duplicate of bug 398 ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links