The autoblock feature intentionally makes these blocks last 1 day (or the length configured on the wiki). It also intentionally blocks only the last used IP address.

There is a trade-off of bundling most code into as few modules as possible and creating too many modules. AFAIK the number of modules that exist is an issue and I've been told to avoid creating new modules unless necessary, because each module name needs to be sent in every request to advertise what can be loaded (from memory)

Some of the other instances of this error are caused by Unable to deliver all events: 503: Service Unavailable. e.g. https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-deploy-1-7.0.0-1-2026.08.13?id=TJdc-58BYIDqwC7cMtni

I spot checked a number of these errors, and they are all related to checkuserSuggestedInvestigationsMatchSignalsAgainstUserJob instances

It will be fine to add this field to the view

Logs stopped after backporting, so looks like this was the issue

Here are the relevant request timeouts and errors that should be fixed by the partial revert:

I've created a partial revert for the CheckUser changes, as the pruning locks are not working and there is a big spike of deadlocks and request timeouts since the change was deployed. More info at T434596: Timeout while waiting for lock in UserAgentClientHintsManager::insertMappingRows

It's causing several issues including request timeouts and PHP out of memory errors, I'm going to revert the lock changes and see if that improves it

Appears to have been caused by 5e02d2f16a8b59bf1a58e673491083d2650d6880. The logs started really going on the 5th of August

4,000 of these in the last 7 days

Back to 100% test coverage 😀

Filed T434585: Create JavaScript documentation for the CaptchaWidget on docs.wikimedia.org for the documentation

updateForFailure is necessary. I would also recommend not calling getCaptchaDataForSubmission until the user has pressed save changes again (because there may be a text box to fill first and for hCaptcha we want users to see the privacy policy links before having hCaptcha executed on their device)

The initial special page exists

// Pull properties for display
SELECT * FROM cusi_case_property
WHERE sicp_stale = 1
AND sicp_sic_id IN (1,2, 3);

Will it be possible to sort the Updated date in the opposite direction? I have used that sort to find the oldest cases and process the backlog in the other direction

In T434383#12198011, @neriah wrote:

Since this feature is currently optional, anyone who doesn't want it can simply choose not to enable it :)

Coverage is now at 41.83%. As Wikimania is over, I'll probably leave this on the backburner for now but there are some more patches to look at if anyone has the time :D

Product Safety and Integrity own blocking, probably good we review this

+1 to JJMC89. If this is for WMF wikis, then maybe this could be a feature each wiki asks for after community consensus is reached to have the feature

Note a naive all.dblist − closed.dblist subtraction is not reliable — as it includes wikis not necessarily in closed.dblist

Yep its a typo, thanks for spotting

The hooks and service exist. They also work as expected on test.wikipedia.org

Changes appear to be working on test.wikipedia.org, moving to done