I'd suggest a new task, that above issue seems related but likely a different fix (and so resurrecting a 2 year old solved task likely complicates getting a fix)

Nope, waiting for code review on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1344794. I'm out for the next two weeks, so if merged before then I will need someone else to run the script too

In T439312#12418826, @dungodung wrote:

In T439312#12373883, @Dreamy_Jazz wrote:

PSI are discussing this internally, we will post here once done

Any news?

Added Product Safety and Integrity sprint as we provided code review

In T191734#8256709, @Jdlrobson wrote:

FWIW I'm not sure I'd recommend bundling MobileFrontend for third parties these days. I think the skin options MediaWiki users have are improving and I'd rather focus on us improving those (see T106463 for example).

I'm going to be WP:BOLD and say given the age of the task and seemingly still blockers that this won't happen and so should be declined

Adding Product Safety and Integrity sprint tag to track code review

UserRightsNotification exists in Notifications (Echo) so any change would need to be to that repository, adding back the project tag based on that

Product Safety and Integrity do not own user rights or user management, I don't think we are best placed to look at this

I think we should leverage the protected variables system to do this, given that we use this for user_unnamed_ip. Filters that need CheckUser level protection are certainly going to use a variable that is just for checkusers (say a new user_ip variable) and adding a new filter visibility type means more complicated logic

Yeah I guess so, didn't see that one

For the Codex version of Special:Block this probably means https://doc.wikimedia.org/codex/latest/components/demos/lookup.html

Thanks, a few hours after the delete this was back to a higher rate:

It got better but then got worse again:

Please check if DNS pods need deleting again. The pod fixing made a significant improvement in failures for calling out to hCaptcha APIs and HTTP requests made entirely within production. But since the 1st of October we have seen that improvement reverse back to where it was before and also at the same time seen more EtcdConfig failures for our periodic scripts:

I wonder if using a variable thay says "this user is a system user" would solve this? Maybe user_type could return system for system users (if a variable to get this doesn't exist)

In T382292#12399563, @Dragoniez wrote:

This makes me wonder whether the user's local attachment status is actually relevant to the global_user_* variables. Would it make sense to remove the ::isAttached() check?

The ticket you link is definitely related, these are the same bug but just different ways to trigger it

This appears to be raising a valid issue, so probably it needs fixing as opposed to disabling the behaviour that causes the issue? I would have thought MediaWiki should support innodb_snapshot_isolation being enabled

While this does allow users to see a count that includes revisions they can't see, I don't think this represents enough of an issue to need a security fix given that usually we are fine with users knowing some limited information about deleted pages in dumps etc.

PSI are discussing this internally, we will post here once done

Vandalism alpha test has been deployed to English Wikipedia stably, so I think we can call this resolved