In T423027#11812690, @IKhitron wrote:

Does this mean I can try to recheck once again now?

Presumably Lucene got that "no space" exception and closed the writer, storing the exception. Then every time it tried to write to the index, an AlreadyClosedException was thrown, wrapping the stored "no space" exception. I restarted Gerrit, that seems to have fixed it. Gate jobs are running now on my core change.

Here's the Gerrit error log when I hit +2 on a core change. Lucene throws an exception with "No space left on device".

There are two other patent pools competing with VIA. Avanci Video offers patent licenses for AV1, H.265, H.266, MPEG-DASH, and VP9, all together in a bundle, for a percentage of video-related revenue. And Access Advance VDP is a pool covering AV1, H.265, H.266 and VP9 which has a royalty waiver tier for small businesses.

In T157614#11770262, @AlexisJazz wrote:

@tstarling Would it make a difference if you used the hardware decoder from an integrated GPU?

In T157614#11769174, @tstarling wrote:

So to use an AVC licensed product, we would have to use some kind of commercial decoder, not FFmpeg.

VIA sells codec licenses for between zero and $0.20 per copy. Licensed products are required to have a EULA statement along the lines of:

This is a historically controversial subject, so community consensus would have to be sought before enabling anything like this. This task is just about implementing the necessary pieces in MW, not the politics of the final results.

In T353891#11704396, @bd808 wrote:

https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ takes 111 seconds to load per FireFox network timing API data collected just now on my home network. That time is all attributed to "waiting". I think it is quite likely that the Python app is doing something inefficient or reliant on an underpowered backend service.

Another failure after the core patch was merged: https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php83/47798/console

1237375 failed gate checks three times in a row, although it failed in a different place each time. First in PHP 8.2, then in PHP 8.3 at split group 5, then in PHP 8.3 at split group 6. Each time with the error message

In T364245#11646191, @Ottomata wrote:

Does this have implications for all post transaction / DeferredUpdate calls/Hooks/DomainEvents? When this happens, is it possible that any post transaction callback will not be run?

It would be nice if we had a diagram or explanation of the whole request flow, including every TCP connection. I see Effie's diagrams at c:Category:Wikimedia servers diagrams with their "it's complicated" boxes, and Timo's backend-focused diagrams, but none of them are really what I need. I've looked into the Envoy service inside the k8s pod in the past, so I should probably have been able to answer my own question, but I do get rusty when I don't have to touch this stuff for a while.

What is the rationale for allowing keepalive on ATS to Apache connections? It's not using HTTPS is it? Inside a datacentre with unencrypted HTTP, the connection latency should be small compared to the average request time.

Extending my detection method to the whole day of 2026-02-18, there were 72 possibly lost RC rows, for an implied loss rate of 0.04%.

In T364245#11487768, @Krinkle wrote:

enwiki

SELECT COUNT(*) FROM revision LEFT JOIN recentchanges ON rev_id = rc_this_oldid AND (rc_source = 'mw.edit' OR rc_source = 'mw.new') LEFT JOIN page ON page_id = rev_page WHERE rev_timestamp LIKE '202512%';
-- Result: 5,295,851

SELECT COUNT(*) FROM revision LEFT JOIN recentchanges ON rev_id = rc_this_oldid AND (rc_source = 'mw.edit' OR rc_source = 'mw.new') LEFT JOIN page ON page_id = rev_page WHERE rev_timestamp LIKE '202512%' AND rc_id IS NULL;
-- Result: 152,168 = 2.8%

So this is not a 5% problem, but a 2.8% problem. Still huge. Let's look at namespaces, again. https://phabricator.wikimedia.org/P86763

• nlwiki: Main 1% gap, Talk 12% gap, User 1% gap, User talk 1% gap, Project 0.6% gap, Template 4% gap, Category 8% gap
• enwiktionary: Main 0.5% gap, User 2% gap, User_talk 3% gap, Template 4% gap, Category 6% gap

The paranoia about sharing state between #invoke calls came out of a complete lack of trust Brad and I had for template developers at the time. In an ideal world, we would just say "please don't do that", and they wouldn't do it. But we were working in an adversarial environment. Remember the time Domas got into a wheel war with the ocwiki admins over slow templates? The attitude was don't worry about performance and template authors told us that if we didn't want them doing a thing, we would have made it impossible. Technical ability to do a thing was treated as permission and our direct communications were given no weight.

This was apparently done on purpose in https://unicode-org.atlassian.net/browse/CLDR-2748

In T411834#11561465, @Amire80 wrote:

It has been proposed that we allow users to deploy Lua code which is stored in Git to multiple wikis.

Proposed by whom?

In T411834#11514785, @tstarling wrote:

In T411834#11476276, @SD0001 wrote:

Maybe, a solution could be to extend Special:TemplateSandbox to allow reading in local code using the File System API.

I did have a couple of ideas, in the task description under the heading "Development cycle", not that one though so thanks for that, I'll consider it.

Increased hash sizes from 32 to 64 bytes to accommodate SHA-256 in hexadecimal format.

I extended the text field types from MEDIUMBLOB to LONGBLOB because the overhead of the extra length byte will be a small percentage of the table size. Limits can be implemented at the application level -- there's no good rationale for making the DB be the first thing to break when someone tries to make a large file.

I added produnto_deployment_data for storing a JSON file mapping the module name to package and file name. Scribunto builds this cache by parsing the package manifest, as described in T412181.

Third-party wikis will want to use packages. Having the GitLab webhook post directly to the wiki is not a solution for them. Also they can't fetch zip files directly from GitLab, there would need to be a CDN.

I created the page.

In T411834#11476276, @SD0001 wrote:

Maybe, a solution could be to extend Special:TemplateSandbox to allow reading in local code using the File System API.

In T412225#11470077, @aaron wrote:

The time felt, off so I timed it, and it is off (15 vs 60 seconds)...

time curl -as 'https://zh.wikipedia.org/w/rest.php/v1/revision/90601530/html'
{"httpCode":504,"httpReason":"upstream request timeout"}

real    0m15.305s
user    0m0.086s
sys     0m0.024s

I updated the schema to make all tables be shared, and also for the new purging algorithm at T412473.

It should simplify purging (T412473) if all tables are shared, since there is a need for global locking. You can check to make sure a package hasn't been touched recently before purging it, but ultimately you need a locked view of that condition.

This is done.

In T362937#11457727, @SD0001 wrote:

So that the data can be used alongside other parser capabilities, like Scribunto's SVG support to generate graphs. It could also be used with Charts, which I now see has a ticket for this use-case: T393500, which would be solved by this patch

We could put the deployments in a shared table, with wiki ID columns.

In T412337#11454743, @Ladsgroup wrote:

I haven't had time to review the proposed schema in depth (I'm in an offsite until next week) but to get the discussion starting, the number of tables per-wiki is still too many[1]. I wonder if the table with one row only can be merged into something else. I don't think these tables will grow much so I'd lean towards de-normalizing as much as possible.

[1] in s3, MariaDB process needs to open many many files because of combination of many wikis and many tables and each table creating two files. Adding three tables to every wiki adds around 6000 more files to be opened by the process which impacts the performance the database.

Why get the parser involved? Why not load from the pageviews API on the client side?

It's reproducible by just putting sleep(1) after the proc_terminate().

In T410527#11399132, @Taylor wrote:

Reportedly LUA can use 50 MiO RAM, quite generous. But if 7'000 pages hog 50 MiO, then every single page consumes ca 7 KiO. Does it really need so much? I could try to call "mw.title.newBatch(...)" in batches of 25 pages, and copy the relevant info from bloated title objects into a LUA table of booleans.

In T279736#11427420, @Nardog wrote:

The "accept" part is resolved, but the "suggest" part is not.

In T355763#9484918, @wmr wrote:

I can't read PHP. ChatGPT says: In this part of the code, if $isEncoding is true and the key $k is a string containing only digits (checked using ctype_digit), it converts the string to an integer using (int)$k. This is done to handle cases where JSON decoding may result in numeric keys represented as strings. The function then checks if the converted integer key forms a sequential sequence.

Is this intended? Is this a bug? If this is intended, can you add an option to allow no conversion like mw.loadJsonData("file.json", digit_conversion=False).