Last modified: 2014-02-19 18:08:00 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 T62798, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 60798 - Database lock time out when renaming an account with 180,000+ edits
Database lock time out when renaming an account with 180,000+ edits
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Renameuser (Other open bugs)
unspecified
All All
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-02-03 23:14 UTC by Trijnstel
Modified: 2014-02-19 18:08 UTC (History)
6 users (show)

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


Attachments

Description Trijnstel 2014-02-03 23:14:58 UTC
An account was renamed on the Dutch Wikipedia (Wikix -> Wikix-oud; Wwikix -> Wikix) due to the original user not being able to login anymore. He forgot his password after he changed it a few times. Wikix has 180,000+ edits, see the rename logs: https://nl.wikipedia.org/w/index.php?title=Speciaal%3ALogboeken&type=renameuser&user=CaAl&page=&year=&month=-1&tagfilter=

The bureaucrat got an error when renaming this account: "database lock time out, please try again". Wikix said he can't login as Wikix so there definitely went something wrong. See also https://nl.wikipedia.org/wiki/Wikipedia:Verzoek_voor_hernoeming_van_account#Wwikix_.E2.86.92_Wikix
Comment 1 MZMcBride 2014-02-03 23:16:26 UTC
This might more appropriately be a Wikimedia bug. Or perhaps two bugs?
Comment 2 Trijnstel 2014-02-17 14:51:05 UTC
Any update on this? He still can't login on Wikix (and uses Wwikix now).
Comment 3 Andre Klapper 2014-02-17 15:57:19 UTC
CC'ing Sean and Brad (database / login territory, though this is user renaming) - wondering if they can help (or know better-suited devs)
Comment 4 Brad Jorsch 2014-02-19 18:08:00 UTC
(In reply to Andre Klapper from comment #3)
> CC'ing Sean and Brad (database / login territory, though this is user
> renaming) - wondering if they can help (or know better-suited devs)

I see a log entry for the lock failure (dberror.log-20140203.gz on fluorine):

Sun Feb 2 12:35:26 UTC 2014     mw1083  nlwiki  RenameuserSQL::rename   10.64.16.25     1205    Lock wait timeout exceeded; try restarting transaction (10.64.16.25)    UPDATE  `user` SET user_name = 'Wikix-oud',user_touched = '20140202123435' WHERE user_name = 'Wikix' AND user_id = '9284'

Looking at the code, it seems that that failure was in the first SQL query for the rename, and should have caused the rest of the rename process not to proceed.

The log entry that is showing up at https://nl.wikipedia.org/w/index.php?title=Speciaal%3ALogboeken&type=renameuser&user=CaAl&page=&year=&month=-1&tagfilter has a timestamp of 2014-02-02 12:35:50.

I wonder whether CaAl had accidentally hit the submit button twice, so the first submission went through while the second timed out waiting on the first.

I also see that the account with user_id 9284 is currently named "Wikix-oud" with a last touched timestamp of 2014-02-02 12:46:50, then there are also both "Wikix" and "Wwikix" users. Both Wikix and Wwikix appear to have email addresses set (slightly different ones) and validated. So the user should be able to recover the password for the nlwiki Wikix account in the normal way unless he no longer has access to that email address for some reason. Wikix-oud has no email set, which I suppose is the reason for the rename in the first place.

SUL-wise, I see that the Wikix user is not attached to the global Wikix account. Which is to be expected since nlwiki's Wikix was renamed and then Wwikix was renamed into its place.

I don't know of any of that was helpful.

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


Navigation
Links