Last modified: 2014-03-20 13:02:09 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 T49848, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 47848 - Renaming a user apparently doesn't reset the cached username associated with that user object
Renaming a user apparently doesn't reset the cached username associated with ...
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: 2013-04-29 21:41 UTC by Ryan Kaldari
Modified: 2014-03-20 13:02 UTC (History)
3 users (show)

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


Attachments

Description Ryan Kaldari 2013-04-29 21:41:13 UTC
Recently, I ran the following on enwiki:
$user = User::newFromId( 84276 );
$user->setOption( 'echo-subscriptions-email-edit-user-talk', 0 );
$user->saveSettings();

This resulted in the following database error:
Error: 1062 Duplicate entry 'Evzob' for key 'user_name'

The reason for this is that user 84276 previously had the username Evzob, but changed their username to something else about 2 months ago. In the meantime, someone else created a new account named Evzob. If you query MediaWiki for the username of user 84276, it still reports it as Evzob two months after it was changed:

> $user = User::newFromId( 84276 );
> print_r( $user->getName() );
Evzob

...but also...

> $user = User::newFromId( 18409122 );
> print_r( $user->getName() );
Evzob

That's from eval.php on enwiki. If you query the database directly, it gives you the up-to-date usernames. Obviously having MediaWiki think there are 2 different users with the same username (for 2 months) is a problem.

To avoid this we should probably do something like:
$user->clearInstanceCache( true );
from Renameuser_body.php around line 460.
Comment 1 Ryan Kaldari 2013-04-29 22:00:22 UTC
I was looking at a rather old version of the Renameuser extension. The place to insert the cache clearing would actually be around line 124 in RenameuserSQL.php.
Comment 2 Gerrit Notification Bot 2013-04-29 22:08:37 UTC
Related URL: https://gerrit.wikimedia.org/r/61491 (Gerrit Change I52f81aacf3d4f8ec7afa058159d07a74c0d9ff9e)
Comment 3 Ryan Kaldari 2013-04-29 23:43:15 UTC
It looks like Renameuser does actually clear the memcached data, but perhaps there is a concurrency issue with the user cache being regenerated before the username change is replicated (or a race condition if the user memcache is regenerated from master). Haven't had time to investigate further. Aaron suggested perhaps salting the user memcache for a minute like FileBackend does.
Comment 4 Andre Klapper 2013-04-30 11:00:52 UTC
I assume this should get fixed before starting Single User Login finalisation?
http://lists.wikimedia.org/pipermail/wikitech-l/2013-April/068937.html
Comment 5 Andre Klapper 2013-10-18 18:59:46 UTC
Is this still an issue in times of SUL? Should this still be high priority?

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


Navigation
Links