Last modified: 2014-03-20 13:02:09 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.
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.
Related URL: https://gerrit.wikimedia.org/r/61491 (Gerrit Change I52f81aacf3d4f8ec7afa058159d07a74c0d9ff9e)
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.
I assume this should get fixed before starting Single User Login finalisation? http://lists.wikimedia.org/pipermail/wikitech-l/2013-April/068937.html
Is this still an issue in times of SUL? Should this still be high priority?