Page MenuHomePhabricator

Possible to globally rename the same user twice (race condition)
Open, HighPublic

Description

2015-04-16T10:06:14 Jianhui67 (talk | contribs) globally renamed Kajnorberg to Kajhaj wiki (m:Special:GlobalRenameQueue/request/11156)
2015-04-16T10:06:13 Stryn (talk | contribs) globally renamed Kajnorberg to Kajhaj wiki (per request)

This shouldn't be possible.

Event Timeline

Legoktm created this task.Apr 16 2015, 3:54 PM
Legoktm raised the priority of this task from to Needs Triage.
Legoktm updated the task description. (Show Details)
Legoktm added subscribers: Legoktm, hoo, csteipp.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 16 2015, 3:54 PM
mysql:wikiadmin@db1033 [centralauth]> select * from renameuser_status;
+------------+-------------+---------+-----------+
| ru_oldname | ru_newname  | ru_wiki | ru_status |
+------------+-------------+---------+-----------+
| Kajnorberg | Kajhaj wiki |         | queued    |
+------------+-------------+---------+-----------+
1 row in set (0.00 sec)

That looks wrong.

Legoktm triaged this task as High priority.Apr 16 2015, 3:57 PM
Legoktm set Security to None.

I've manually deleted the bad renameuser_status row and unlocked the account.

Well, perhaps both Stryn and I were coincidentally on the same page and we were going to approve the ticket. Stryn was slightly faster than me, and did the local renames. However, my name was reflected on the ticket.

Stryn added a subscriber: Stryn.Apr 16 2015, 4:10 PM

Well, perhaps both Stryn and I were coincidentally on the same page and we were going to approve the ticket. Stryn was slightly faster than me, and did the local renames. However, my name was reflected on the ticket.

Yeah that's fine and totally reasonable, but the software should have rejected one of the attempts since one was already in progress, which is what this bug is about.

Change 204637 had a related patch set uploaded (by Hoo man):
Fix CentralAuthUser::loadAttached if no accounts are attached

https://gerrit.wikimedia.org/r/204637

Change 204637 merged by jenkins-bot:
Fix CentralAuthUser::loadAttached if no accounts are attached

https://gerrit.wikimedia.org/r/204637

Change 204638 had a related patch set uploaded (by Legoktm):
Fix CentralAuthUser::loadAttached if no accounts are attached

https://gerrit.wikimedia.org/r/204638

Change 204639 had a related patch set uploaded (by Legoktm):
Fix CentralAuthUser::loadAttached if no accounts are attached

https://gerrit.wikimedia.org/r/204639

Change 204638 merged by jenkins-bot:
Fix CentralAuthUser::loadAttached if no accounts are attached

https://gerrit.wikimedia.org/r/204638

Change 204639 merged by jenkins-bot:
Fix CentralAuthUser::loadAttached if no accounts are attached

https://gerrit.wikimedia.org/r/204639

hoo closed this task as Resolved.Apr 16 2015, 9:59 PM
hoo claimed this task.
hoo removed a project: Patch-For-Review.
Shanmugamp7 reopened this task as Open.Apr 21 2015, 9:52 AM

Seems it happens again

15:11 . . Shanmugamp7 (talk | contribs | block) globally renamed Kic~eswiki to Kic.Mad ‎(see m:Special:GlobalRenameQueue/request/11959)
15:11 . . Jmvkrecords (talk | contribs | block) globally renamed Kic~eswiki to Kic.Mad ‎(see m:Special:GlobalRenameQueue/request/11959)

This has happened multiple times as well. This should be a software bug.

hoo added a comment.Apr 21 2015, 12:43 PM

The thing I've fixed probably was just a symptom of this, the root cause is something else.

<anomie> csteipp: The only thing I can think of for T96267 is if the second submission gets an empty array from $this->oldCAUser->listAttached(), it'll happily do no local renames but still add another log entry.

So sounds like the second log entry may not indicate that anything was actually renamed. We should probably show a warning to the renamer in that case?