Page MenuHomePhabricator

Global account not appearing on Special:GlobalUsers – do maintenance/runBatchedQuery.php
Closed, ResolvedPublic

Details

Reference
bz30185

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:49 PM
bzimport set Reference to bz30185.
bzimport added a subscriber: Unknown Object (MLST).
Reedy added a comment.Aug 5 2011, 6:10 PM

-shell for the moment

It seems like it's a bug with CentralAuth for some reason

Reedy added a comment.Nov 16 2011, 4:01 PM

http://meta.wikimedia.org/w/index.php?title=Special:ListUsers&limit=500&username=Hos

Hosinheidari (Created on 4 November 2011 at 00:49)
Hosiryuhosi‏‎ (autopatroller) (Created on 14 January 2008 at 15:20)
HosiryuhosiBot (Created on 8 August 2009 at 15:52)

It's there in the list, so this isn't a major bug

Rxy added a comment.Nov 16 2011, 4:07 PM

It's Local User List(Special:ListUsers)...

(In reply to comment #3)

It's Local User List(Special:ListUsers)...

I've just found that when searching in Special:GlobalUsers it redirects your search to Special:ListUsers for no apparent reason, when this should not happen and never happened before. Maybe MW1.18 or recent changes in the Extension?

I'll fill a separate bug for this and link it to this bug.

Normal not-hidden users have gu_hidden='', and that's what is used to filter that list. However, both Hosiryuhosi and HosiryuhosiBot have gu_hidden = '0'. which is why they aren't shown by Special:GlobalUsers

gu_hidden was changed from a boolean to a varchar in r62827. Seems there are 678 which didn't get converted to '' afterwards.
Tim Starling, Lupo, Eloquence, Balderai, TheDJ, Emijrp, Magister...

The fix is just a matter of running
maintenance/runBatchedQuery.php --wiki=metawiki "UPDATE centralauth.globaluser SET gu_hidden='' WHERE gu_hidden = '0' LIMIT 50"

quentinv57 wrote:

(In reply to comment #4)

(In reply to comment #3)

It's Local User List(Special:ListUsers)...

I've just found that when searching in Special:GlobalUsers it redirects your
search to Special:ListUsers for no apparent reason, when this should not happen
and never happened before. Maybe MW1.18 or recent changes in the Extension?

I'll fill a separate bug for this and link it to this bug.

I already reported this bug, please see #32278.

To me, this bug is not minor at all... some users exists and are not displayed on the user list. And this problem may hide some others with those accounts.

vigorous_action wrote:

Why isn't it processed?
Not being displayed on GlobalUsers is very inconvenient.
It desires to be improved immediately.

(updating blocker marked duplicate)

brion added a comment.Jan 3 2012, 7:09 PM

Deassigning as I'm not active on this ext and haven't picked up the bug myself.

Dropping priority since I didn't really provide a good reason for bumping up priority.

Reedy added a comment.Mar 27 2012, 3:00 PM

(In reply to comment #6)

gu_hidden was changed from a boolean to a varchar in r62827. Seems there are
678 which didn't get converted to '' afterwards.
Tim Starling, Lupo, Eloquence, Balderai, TheDJ, Emijrp, Magister...

The fix is just a matter of running
maintenance/runBatchedQuery.php --wiki=metawiki "UPDATE centralauth.globaluser
SET gu_hidden='' WHERE gu_hidden = '0' LIMIT 50"

All done now

quentinv57 wrote:

Reopening this bug.

MBisanz, one of our stewards, is not shown at [[Special:GlobalUsers]]. If this could be reviewed not only for this account but for every SUL account (already created or to be created), it would be appreciated.

Thanks.

Quentinv57

I see 75 users with gu_hidden='0' right now (including MBisanz).

Rerunning the command provided in comment 6 should fix it.

Registration date go from 20080325 to 20100311. They failed to convert in comment 12 run? Or is something placing 0s there?

For reference, the currently affected accounts are:
+---------+-----------------------------+-----------+

gu_idgu_namegu_hidden

+---------+-----------------------------+-----------+

127TwinsMetsFan0
281Stefan640
554MBisanz0
628Przykuta0
773Law soma0
1047Bukaj0
1216Balderai0
1465MiPe0
3119Tnxman3070
3924Ykhwong0
4320Kpisimon0
4726Gleiberg0
4832Mpfiz0
4970BrokenSphere0
5015Ark0
5412Jacklee0
5487SatuSuro0
6568Flopy0
7576BerlinerSchule0
8513Chatter0
8893NordNordWest0
8964Bogorm0
10258Annika640
10847Arjuno30
15043Gerd W. Zinke0
25666Maniago0
25721AnakngAraw0
31527Romano12460
31993Pittimann0
32996Kriddl0
47104Dangelin50
673221TomStar810
1172575Chris G Bot 30
1275503Mild Bill Hiccup0
1383081ArikamaI0
1495647Hystrix0
1624896Cp1110
1815750Cekli8290
1873437Raniero Supremo0
1996417Lahcim nitup0
2127136Mariusz760
2159609Richard Harvey0
2199873David J Wilson0
2245572Tide rolls0
2259419Seibun0
2299822Farary0
2395484Cocu0
2420698Lonelydarksky0
2435138Patafisik0
2805136Mnsch0
2867994Caig0
2891713Lokiseinchef0
2991818Groovenstein0
3012014Newwhist0
3435552Henrig0
3449767Jujutacular0
3489690High Contrast0
3836651Jerchel0
3911620Baird's Tapir0
3992956Seb az865560
4073559Astynax0
4232486Taxiarchos2280
4254937Korrekturen0
4321844Rilegator0
4343556Mabeenot0
4611435ThF0
4630290Claudioverfuerth0
5104118Tuba Mirum0
5165607B201800
5191571KarlV0
5234734Ohlumon0
5318524WTM0
5444285Zollerriia0
5597617Pablo0000
6121502José Luís Ávila Silveira0

+---------+-----------------------------+-----------+

The command in comment 6 which was run by Reedy had LIMIT 50, which is probably why it didn't get all the bad accounts.

Bump. Shell users, can you consider running the command again, this time with a higher limit, please?

Reedy added a comment.Jan 17 2013, 4:36 PM

(In reply to comment #15)

The command in comment 6 which was run by Reedy had LIMIT 50, which is
probably
why it didn't get all the bad accounts.

Not really.

Considering this is now like, 10 months ago, I obviously cannot remember what I ran.

Have you actually looked at the maintenance script? It runs in batches. And while there are more than 0 rows affected, it goes and runs it again...

		$this->mDescription = "Run a query repeatedly until it affects 0 rows, and wait for slaves in between.\n" .
				"NOTE: You need to set a LIMIT clause yourself.";
Reedy added a comment.Jan 17 2013, 4:40 PM

reedy@fenari:/home/wikipedia/common$ mwscript runBatchedQuery.php --wiki=metawiki "UPDATE centralauth.globaluser SET gu_hidden='' WHERE gu_hidden = '0' LIMIT 50"
Batch 1: 50 rows
Batch 2: 25 rows
Batch 3: 0 rows

However, I still see 35 users with gu_hidden = '0'.

mysql> select gu_id, gu_name from globaluser where gu_hidden='0';
+---------+------------------+

gu_idgu_name

+---------+------------------+

25721AnakngAraw
10258Annika64
1383081ArikamaI
10847Arjuno3
5015Ark
4073559Astynax
5165607B20180
1815750Cekli829
8513Chatter
1172575Chris G Bot 3
2395484Cocu
47104Dangelin5
2199873David J Wilson
15043Gerd W. Zinke
4726Gleiberg
2991818Groovenstein
3435552Henrig
3489690High Contrast
5191571KarlV
4320Kpisimon
773Law soma
2420698Lonelydarksky
1465MiPe
1275503Mild Bill Hiccup
3012014Newwhist
8893NordNordWest
31993Pittimann
2159609Richard Harvey
3992956Seb az86556
4611435ThF
673221TomStar81
127TwinsMetsFan
5318524WTM
3924Ykhwong
5444285Zollerriia

+---------+------------------+

Maybe the value is overwritten if they were using their account when the script ran? These entries refuse to be fixed... :S

Reedy added a comment.Jan 27 2013, 3:34 AM

(In reply to comment #19)

However, I still see 35 users with gu_hidden = '0'.

You listed 75, I fixed 75..

mysql:wikiadmin@db1041 [centralauth]> select gu_id, gu_name from globaluser where gu_hidden='0';
+---------+------------------+

gu_idgu_name

+---------+------------------+

25721AnakngAraw
10258Annika64
1383081ArikamaI
10847Arjuno3
5015Ark
4073559Astynax
5165607B20180
1815750Cekli829
8513Chatter
1172575Chris G Bot 3
2395484Cocu
47104Dangelin5
2199873David J Wilson
15043Gerd W. Zinke
4726Gleiberg
2991818Groovenstein
3435552Henrig
3489690High Contrast
5191571KarlV
4320Kpisimon
773Law soma
2420698Lonelydarksky
1465MiPe
1275503Mild Bill Hiccup
3012014Newwhist
8893NordNordWest
31993Pittimann
2159609Richard Harvey
3992956Seb az86556
4611435ThF
673221TomStar81
127TwinsMetsFan
5318524WTM
3924Ykhwong
5444285Zollerriia

+---------+------------------+
35 rows in set (1 min 35.67 sec)

mysql:wikiadmin@db1041 [centralauth]> ^CCtrl-C -- exit!
Aborted
reedy@fenari:~$ mwscript runBatchedQuery.php --wiki=metawiki "UPDATE centralauth.globaluser SET gu_hidden='' WHERE gu_hidden = '0' LIMIT 50"
Batch 1: 35 rows
Batch 2: 0 rows
reedy@fenari:~$ sql centralauth
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 63981963
Server version: 5.1.53-wm-log (mysql-at-facebook-r3753)

Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql:wikiadmin@db1041 [centralauth]> select gu_id, gu_name from globaluser where gu_hidden='0';
Empty set (5.65 sec)

mysql:wikiadmin@db1041 [centralauth]> ^CCtrl-C -- exit!
Aborted
reedy@fenari:~$

Not a lot more I can do than that...

However, I still see 35 users with gu_hidden = '0'.

You listed 75, I fixed 75..

And 35 of them then returned to the wrong version.

Just as there are 18 back to '0' now:
mysql> select gu_id, gu_name from globaluser where gu_hidden='0';
+---------+------------------+

gu_idgu_name

+---------+------------------+

25721AnakngAraw
1383081ArikamaI
4073559Astynax
5165607B20180
1172575Chris G Bot 3
2199873David J Wilson
15043Gerd W. Zinke
4726Gleiberg
2991818Groovenstein
3435552Henrig
4320Kpisimon
1275503Mild Bill Hiccup
3992956Seb az86556
673221TomStar81
127TwinsMetsFan
5318524WTM
3924Ykhwong
5444285Zollerriia

+---------+------------------+
18 rows in set (2 min 47.17 sec)

Yes, I know that it should have been fixed, and I don't understand either what's reverting them...

Reedy added a comment.Jan 27 2013, 3:53 PM

(In reply to comment #21)

Yes, I know that it should have been fixed, and I don't understand either
what's reverting them...

Are they in Memcached? Being loaded from their and then updated to the database when something else happens? Can we just hack in a conversion on load and wait a little while?

Gerrit change 46036

(In reply to comment #23)

Gerrit change #46036

As this patch was merged: Is it expected to fix the problem in this bug report completely?

Reedy added a comment.Jan 28 2013, 3:50 PM

The patches have been merged to cluster. It'll probably take a few days before it's fixed, depending on activity of those users.

Although I can fix it in the database (third time lucky), I think it makes more sense to let MediaWiki fix it itself. The bug might aswell stay open for now, and check on progress in a few days.

Reedy added a comment.Feb 2 2013, 10:41 PM

mysql:wikiadmin@db1041 [centralauth]> select gu_id, gu_name from globaluser where gu_hidden='0';
Empty set (2 min 12.78 sec)