Page MenuHomePhabricator

Unable to generate user impact for user in RefreshUserImpactJob.
Closed, ResolvedPublicPRODUCTION ERROR

Description

Error
normalized_message
Unable to generate user impact for user in RefreshUserImpactJob.
Impact

As far as I can see, none apart from logspam.

Notes

This happens on eswiki where one of the users meeting the conditions is suppressed.

Details

Request URL
https://jobrunner.discovery.wmnet/rpc/RunSingleJob.php

Event Timeline

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

This happens on eswiki where one of the users meeting the conditions is suppressed.

I missed that. Yeah, the user is globally blocked. So, I guess we could use improved logging here. Should we not generate impact data for blocked users?

This happens on eswiki where one of the users meeting the conditions is suppressed.

I missed that. Yeah, the user is globally blocked. So, I guess we could use improved logging here. Should we not generate impact data for blocked users?

I think we definitely shouldn't generate impact data for hidden users (User::isHidden), as those users are unable to log in and for all but few highly-privileged users, MediaWiki behaves as if those users didn't exist at all.

Having impact data for blocked users (while not hidden) can be helpful, because blocked users can: (a) visit their homepage (b) edit, if the block is a partial one.

I think we definitely shouldn't generate impact data for hidden users (User::isHidden),

Agreed. I think that's the work to do for this task, then.

Urbanecm_WMF triaged this task as Medium priority.

Change 925745 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/GrowthExperiments@master] Do not refresh impact data for hidden users

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

Change 925745 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Do not refresh impact data for hidden users

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

Etonkovidova subscribed.

No errors have been recorded for wmf.12 - the last timestamp Jun 8, 2023 @ 07:45:31.691 (logstash link).