@Aklapper any updates?

@Lucas_Werkmeister_WMDE Who actually has the authority to decide whether to merge it? The bug has been open for years now.

@tstarling Could you please review my fix? https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Scribunto/+/1347289 Since I caused this problem in the first place, I'd like to get the fix merged as soon as possible.

Regression from rELUAb109cb6e5866 (wmf.22): {{#invoke:}} now fails when a function returns nil before other values, which cawiki's Mòdul:Wikidades does for every missing property. Fix with test: https://gerrit.wikimedia.org/r/1347289

Looked into this; the patch above is the proposed fix.

Upstream has fixed the Phan limitation this task is blocked on.

Retitled: the problem is broader than ucfirst(), and broader than ord().

Declining this as stale, and as not really a PHP 8.1 issue.

I can no longer reproduce any of these, and the checklist in the description is effectively complete.

This was fixed in June 2023.

This looks fixed. UrlHistoryHandler::jsonSerialize() now declares the mixed return type that JsonSerializable requires under PHP 8.1+:

This is already fixed in master and in all release branches from REL1_44 onward.

Closing this as Declined — it's no longer actionable against supported code.

@Lucas_Werkmeister_WMDE and @Lydia_Pintscher any updates?

I can not reproduce it, the size of the image is correct now

@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.

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.