Change 1263482 rolled out to group-1 wikis. I checked itwiki and hewiki, and several top-10 articles had their TTL extended from midnight to a full month. Two examples:

Ah, yep:

In T416616#11761371, @Bewfip wrote:

Module:Citation/CS1 also validates access-date, which is probably just a little bit less widespread than specifying the year of the source.

The biggest opportunity is making the cache TTL of os.date('%Y') extend to the year boundary, since that would cover Module:CS1, which is the most common TTL-constraining module across a wide array of wikis. That doesn't require new APIs, just a modest improvement to the current TTL code to handle coarser units than a day. I'm starting with that.

I had an AI agent analyze the current-date / current-time semantics of the Lua modules from T416616#11711690.

Below is a summary of the TTL sources I found in the top 150 most-viewed pages in 2025 across zhwiki, jawiki, arwiki, fawiki, kowiki, viwiki, ruwiki, hewiki, thwiki, and hiwiki. For convenience and future reference, I’ve also included the LLM-generated scripts I used to collect and summarize the data, along with the raw JSON report.

In T416616#11675624, @cscott wrote:

I updated the miser mode patch as described in the previous comment.

@cscott Thanks for the explanation. That sounds reasonable.

In T416540#11614737, @Bewfip wrote:

A slightly OT question: When I see Cache expiry: 1807, is it possible to identify the reason for it? I suspect it comes from the MIN_DEADLINE_TTL (30*60=1800) in CoreMagicVariables.php. The method I have found so far is bisecting a page's source code, and inspect the NewPP report by previewing.

An instance I found on zhwiki (template) is caused by invocation of {{#time:}}, resulting from gerrit #1201838.

Getting back to the initial proposal in the task description: I'm realizing editors won't adopt these interfaces unless the calendar arithmetic is exactly consistent with what existing modules provide. I looked at Module:Date and Module:Age on enwiki in detail, but I'd like to do a broader survey. Here's my proposal:

In T416616#11630078, @cscott wrote:

I think ultimately we're going to have to surface the list of pages with short expiry times in some way visible to wiki gnomes, who can then help us keep the size of that list to a reasonably small number.

In T416616#11623705, @Bewfip wrote:

I saw usage of math.randomseed(), where the timestamp is used to seed the PRNG. Should there be a way to obtain the time without parser cache side effect?

In T416616, @cscott wrote:

We will probably also need to provide ways to identify pages which are currently cache-unfriendly and motivate conversion to the new parser function. Using a "Expires daily" tracking category might be a good start, but it might have too many pages in it.

This is a fantastic idea!

Is the spike caused by more requests or more work per request?

@Stitipragyan_barik please read https://www.mediawiki.org/wiki/New_Developers#Communication_tips.

Thank you for tagging this task with good first task for Wikimedia newcomers!

This is a good first task for developers familiar with Lua (or willing to learn). Here is where the Lua implementation of gsub is located: includes/Engines/LuaCommon/lualib/ustring/ustring.lua, lines 945-1055

So, the avoiding the eager evaluation of var_export() did the trick. 🎉

In T253461#6192041, @Ladsgroup wrote:

• Has any sort of profiling done on @ and AtEase, one might be quite faster. We should check.

Prior art: https://cs.symfony.com/doc/rules/function_notation/native_function_invocation.html

A few points in favor of a global rule:

The cookie has been defunct for almost a decade. The code should be deleted.

Obsolete, as MediaWiki now requires PHP 8.1.0+

freeResults() was fully removed in 1.39:

@akosiaris Do you have any suggestions for getting this task un-stuck?

I cleaned up the residual instances manually on arclamp1001 and arclamp2001.

Deploying this to all Wikipedias would be risky. Chess is very popular, and without a dedicated team for this extension, bug reports and feature requests could pile up quickly.

With T362586 resolved, I believe the final TODO is complete.

Are there active TCP sockets on the client app server matching the sleeping MySQL sessions? Knowing this would help pinpoint whether these are idle connections that are held by PHP workers or if these are orphaned (half-opened) connections.

Ack, thanks for the heads up.

Hi, and thanks!

@VirginiaPoundstone Sorry for the delay. Yes, that should do the trick. Thank you.

Hi Mark! Could you summarize the back-and-forth? What were the alternatives considered?

In lieu of exporting a route map, MediaWiki could, as a first pass at the problem, emit a response header that signals to the CDN that a request contained garbage parameters. The CDN could use this information to throttle clients that issue too many such requests. This may be less desirable than filtering all such requests at the edge, but it is also simpler.

It's a bug in webhint, AFAICT. It thinks stale-while-revalidate should not hold a value, but that is wrong. This is the problematic code:

In T211661#9054485, @MatthewVernon wrote:

The other thing I can't quite leave alone is - why are we being asked for some thumbnails so often? Shouldn't the CDN be caching thumbs? If we served each thumb only once in that 24 hour period, that would have saved about 54 million requests to swift (which is 29% of the requests swift served), which is non-trivial...

Commonest-served thumbs on that day (with request counts):

8924 wikipedia-commons-local-thumb.8e/8/8e/Edit_remove.svg/15px-Edit_remove.svg.png
8053 wikipedia-commons-local-thumb.2c/2/2c/Broom_icon.svg/22px-Broom_icon.svg.png
6268 wikipedia-commons-local-thumb.de/d/de/Wynn.svg/25px-Wynn.svg.png
6264 wikipedia-commons-local-thumb.33/3/33/Crystal_Clear_action_viewmag.png/22px-Crystal_Clear_action_viewmag.png
6258 wikipedia-commons-local-thumb.1e/1/1e/Font_Awesome_5_solid_arrow-down.svg/19px-Font_Awesome_5_solid_arrow-down.svg.png
6256 wikipedia-commons-local-thumb.b2/b/b2/Font_Awesome_5_solid_arrow-up.svg/19px-Font_Awesome_5_solid_arrow-up.svg.png
5706 wikipedia-commons-local-thumb.b3/b/b3/Broom_icon_ref.svg/22px-Broom_icon_ref.svg.png
4990 wikipedia-commons-local-thumb.33/3/33/Crystal_Clear_action_viewmag.png/21px-Crystal_Clear_action_viewmag.png

I also don't know how well Swift would handle 15k QPS of object metadata updates (cf T211661#8377883)

Right. Now I remember. The initial expiration is indeed supposed to be set by Thumbor. The necessary functionality had some trouble landing in the Wikimedia Thumbor plugin repo, but it has since landed.

@MatthewVernon: my understanding is that rewrite.py is currently setting expiry headers for thumbnails on retrieval from Swift -- is that correct, and does that mean some thumbnails are already getting expired?

This is really confusing.

Vega ships an optional interpreter that can evaluate graph expressions by traversing an AST and performing each operation, rather than relying on runtime code generation. Per https://github.com/vega/vega/pull/3019#issuecomment-749107902, the interpreter mode is not the default because it is 10% slower. Seems like a negligible price to me. This seems like the only sensible option for keeping support for graph expressions but rooting out XSS vectors systematically.

@phuedx I don't know, sorry.

Does the edits graph in T327440#8542723 include bots? Bots may not be a large proportion of users but they do contribute a large proportion of edits.

+1 to @Tgr's proposal

It might be worth it to try and contact the library's co-maintainer. His contact info is at https://eatingco.de/about/.

ㅤ

@Jdforrester-WMF : the Beta Cluster instance of the function-evaluator now runs under GVisor. Some additional work will be required to make the production instance of the function-evaluator run under GVisor. There is documentation here: https://gvisor.dev/docs/user_guide/quick_start/kubernetes/.

I created a new task for the alerts, T321099. Let's continue there.

Wikifunctions on the Beta Cluster uses the *.wikimedia.beta.wmflabs.org wildcard cert, and the CertAlmostExpired alert was caused by automatic certificate renewal being broken on the Beta Cluster in general. T293585 is the issue; it looks like Valentin and Giuseppe fixed it.

@phuedx I'm not aware of anything actively using it, no, but I'm also out of the loop -- can you ask someone on the performance team to confirm?

Done by Ali: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Semantics_of_Wikifunctions

Relevant: Provably-Safe Multilingual Software Sandboxing using WebAssembly

I've cherry-picked the two Puppet patches on the beta cluster. The mediawiki-function-evaluator service is now running under gVisor.

Never mind, I see that it is available for Bullseye -- sorry.

@Joe the Wikifunctions Beta Cluster instance is running Bullseye -- could you also pull it in there?

There are no outstanding issues that are specific to the Beta Cluster environment, AFAIK.

@cmassaro We have some logging now, and instructions on Wikitech on how to access the logs. I think there are more places where we can add additional logging to make debugging easier, but that is better dealt with on an ongoing basis than a dedicated task.