Page MenuHomePhabricator

UserInfo appears to report incorrect GlobalContributions count
Closed, ResolvedPublic1 Estimated Story PointsBUG REPORT

Description

The Problem:
  • Example 1: User:Bosco Sin
    • GlobalContributions count on CentralAuth and XTools both report 19,136 edits (as of writing this task)
    • UserInfo for Bosco Sin on testwiki shows 31,463
  • Example 2: User:Paloi Sciurala

Other information (browser name/version, screenshots, etc.): Reported on wiki: https://www.mediawiki.org/wiki/Talk:Trust_and_Safety_Product/Anti-abuse_signals/User_Info#Incorrect_global_contributions_count

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

As noted in T300075#10974401, it seems that there are two different methods in use in CentralAuth for calculating a global edit count, and that's why the discrepancy appears between UserInfo and Special:CentralAuth.

If it helps, take a look at T313900 - I believe that this issue is related to username changes, with one of the edit count calculation methods presumably counting a user's pre-rename edits twice.

I renamed my account back in 2022, and I've been affected by this problem (hence that other issue), and it appears that User:Bosco Sin and User:Paloi Sciurala changed their account usernames as well - and have been impacted by the same problem as myself.

Anyway, it seems that the CentralAuthEditCount.getCountFromWikis(CentralAuthUser $centralUser) method does correctly calculate edit counts, but the overall CentralAuthEditCount.getCount(CentralAuthUser $centralUser) method doesn't (I suspect that the problem may be within CentralAuthEditCount.getCountFromDB( IReadableDatabase $dbr, int $userId )). No idea how to poke around with that myself, but I figured I may as well say something to help you to narrow things down a bit.

kostajh set the point value for this task to 1.Jul 23 2025, 10:22 AM

If it helps, take a look at T313900 - I believe that this issue is related to username changes, with one of the edit count calculation methods presumably counting a user's pre-rename edits twice.

I renamed my account back in 2022, and I've been affected by this problem (hence that other issue), and it appears that User:Bosco Sin and User:Paloi Sciurala changed their account usernames as well - and have been impacted by the same problem as myself.

Anyway, it seems that the CentralAuthEditCount.getCountFromWikis(CentralAuthUser $centralUser) method does correctly calculate edit counts, but the overall CentralAuthEditCount.getCount(CentralAuthUser $centralUser) method doesn't (I suspect that the problem may be within CentralAuthEditCount.getCountFromDB( IReadableDatabase $dbr, int $userId )). No idea how to poke around with that myself, but I figured I may as well say something to help you to narrow things down a bit.

Thanks @HotMess!

I agree that we should make use of getCountFromWikis() to resolve this task.

Change #1172655 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/CheckUser@master] UserInfoCard: Use CentralAuth's getCountFromWikis for global edit count

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

Change #1172655 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] UserInfoCard: Use CentralAuth's getCountFromWikis for global edit count

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

Djackson-ctr subscribed.

New Code Changes have been implemented (UserInfoCard: Global Edits Count matches CentralAuth & Xtools):
QA was completed for this ticket using Mediawiki 1.45.0-wmf.12 (4f0e620)
Testing was performed on various: Skins, Desktop View/MobileView, Chrome/Edge/Firefox/Safari, Windows/Mac/Android/iOS, RTL languages

Since T313900 is about to be fixed, you could probably revert your workaround, which is really slow (getCountFromWikis() has to query every local wiki's database where the user exists).

Since T313900 is about to be fixed, you could probably revert your workaround, which is really slow (getCountFromWikis() has to query every local wiki's database where the user exists).

This is now filed as T401708, so I guess this task is done.