@Johannnes89 You filtered the log by performer = MediaWikiAccountBackfiller. The only entry that ever carried that performer was the forcecreatelocal entry, which my commit deliberately eliminated. That was the whole point: to stop attributing a RecentChange to the backfiller so it would no longer pollute CheckUser.

@Lydia_Pintscher the patch is ready to be merged. Can you (or someone else) have a look? the current behavior is a bug anyway.

@taavi I see that no one is interested in reviewing my second pull request, so I’m thinking of abandoning it.

attemptAutoCreateLocalUserFromName() creates two newusers log entries:

@Tgr Could you have a look? This is a really small patch.

@Jdforrester-WMF, can you also look at the follow-up: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Scribunto/+/1258717?

Just to make sure: this issue only affects Toolforge, i.e., Cloud Services, right? Is ingress-nginx also used on the production Kubernetes cluster that serves production traffic?

@cscott I’ve replied to your comment on Gerrit.

@Ifeatu_Nnaobi_WMDE any updates?

Fixed in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Scribunto/+/1265609

@Umherirrender I’ve prepared a follow-up patch that fixes this.

TextLibrary::getEntityTable() uses array_flip(get_html_translation_table()) to build the entity decode table. PHP's get_html_translation_table() returns only one canonical entity name per character, so array_flip() loses all aliases. For example, PHP picks "ε" as canonical for ε (U+03B5), so "ε" is missing from the table and left as undecoded literal text. My patch will fix it.

The response appears to be coming from a Swift-backed object where the original object metadata is preserved through the cache layer. In other words, the Content-Type: application/ogg header is most likely stored as object metadata, rather than being set dynamically by Envoy or another frontend component.

Sorry, my bad.

@taavi This is the second attempt, where I made several different choices compared to the previously abandoned patch. I chose django-cas-ng instead of social-auth-app-django, mainly because it is single-purpose and has a minimal footprint. Additionally, instead of using a proper CAS setup for local development (until T412826 is finished), I added a minimal CAS Python server for local development.

Nuke uses the standard MediaWiki deletion mechanisms:

I have submitted the patch.

When Nuke deletes file pages (NS_FILE), it calls FileDeleteForm::doDelete() synchronously rather than via the job queue. If getAllPages() returns the same file page twice (because it uses array_merge without deduplication), doDelete() is invoked twice for the same page.

@Jdforrester-WMF Here the patch — you can have a look.

@mszwarc I have submitted the fix for this specific bug. The CI failed due to an unrelated problem in the CommunityConfiguration extension.

I can confirm I experienced the same issue on Wikidata. I made an edit and everything seemed fine, but it wasn’t saved and doesn’t appear in the history.

Sorry, I didn’t realize that the same pattern is also in the WikibaseLexeme repository. Does Gerrit allow searching across all repositories?

@Jdforrester-WMF I finally fixed all CI errors. The merge order is now Scribuntu → JsonConfig. The latter removes the temporary suite() workaround for the old Scribunto, which was needed because of a dependency cycle.

@Jdforrester-WMF The merge order needs to be: Core → JsonConfig → Scribunto. I’m not very familiar with Gerrit’s Depends-On feature yet, but that was my plan.

I think this particular issue can be closed, and future work will continue under T328919, right? If there are no objections, I will close this ticket.

I have submitted a minimal fix to get the CI tests passing:
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Scribunto/+/1243176
(Fix toString() format to avoid breaking PHPUnit extensions),

The change in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1148424
caused T418217: the new ergebnis/phpunit-slow-test-detector extension assumes that the toString() output of tests follows the ClassName::methodName convention. Scribunto’s custom toString() prepends EngineName: , which breaks that assumption. I submitted a patch that hopefully fixes this: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Scribunto/+/1243176

The new ergebnis/phpunit-slow-test-detector extension (added in core commit b89692aa8c8 on Feb 23) assumes the toString() output of tests follows the ClassName::methodName convention. Scribunto's custom toString() prepends "EngineName: ", breaking that assumption.

1. ergebnis/phpunit-slow-test-detector resolveMaximumDuration() receives test name "LuaStandalone: SomeClass::testMethod", splits on :: to get $testClassName =
2. "LuaStandalone: SomeClass"
3. It calls PHPUnit\Util\Test::parseTestMethodAnnotations("LuaStandalone: SomeClass", "testMethod")
4. Which calls Registry::forClassName("LuaStandalone: SomeClass")
5. Which does new ReflectionClass("LuaStandalone: SomeClass") at line 56
6. That throws ReflectionException → converted to PHPUnit Exception at line 59
7. This propagates up and crashes the test run

Regardless of whether we want the full feature (connecting redirects with a badge), the current behavior is a bug that should be fixed: when a user opens the "Add links" widget on a redirect page, the page normalizer follows the redirect, and the resulting merge can corrupt the redirect target's item. At minimum, we should either prevent that incorrect merge or handle it properly.

@Tacsipacsi thanks for the review. I’ve addressed your comments, in particular by switching to a Codex CSS-only notice (cdx-message--notice) with mediawiki.codex.messagebox.styles.
Migrating the whole widget from jQuery UI to Codex sounds like a good idea, but I think that deserves its own ticket, since this patch is focused on allowing redirect pages to be connected.

Has this resolved the issue? Is the script now working correctly? Could one of the CheckUsers or stewards please check it?

The failing tests are unrelated to this patch and are also failing on master. The patch has been tested locally and is ready for review and merge.

What is the current status of this ticket?