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.
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.
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
Change 204637 merged by jenkins-bot:
Fix CentralAuthUser::loadAttached if no accounts are attached
Change 204638 had a related patch set uploaded (by Legoktm):
Fix CentralAuthUser::loadAttached if no accounts are attached
Change 204639 had a related patch set uploaded (by Legoktm):
Fix CentralAuthUser::loadAttached if no accounts are attached
Change 204638 merged by jenkins-bot:
Fix CentralAuthUser::loadAttached if no accounts are attached
Change 204639 merged by jenkins-bot:
Fix CentralAuthUser::loadAttached if no accounts are attached
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)
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?
This task has been assigned to the same task owner for more than two years. Resetting task assignee due to inactivity, to decrease task cookie-licking and to get a slightly more realistic overview of plans. Please feel free to assign this task to yourself again if you still realistically work or plan to work on this task - it would be welcome!
For tips how to manage individual work in Phabricator (noisy notifications, lists of task, etc.), see https://phabricator.wikimedia.org/T228575#6237124 for available options.
(For the records, two emails were sent to assignee addresses before resetting assignees. See T228575 for more info and for potential feedback. Thanks!)