Page MenuHomePhabricator

Renaming a user apparently doesn't reset the cached username associated with that user object
Open, MediumPublicBUG REPORT

Description

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.


Version: unspecified
Severity: major

Details

Reference
bz47848

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:21 AM
bzimport set Reference to bz47848.
bzimport added a subscriber: Unknown Object (MLST).

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?

Aklapper changed the subtype of this task from "Task" to "Bug Report".Feb 15 2022, 9:39 PM
Aklapper removed a subscriber: wikibugs-l-list.