In T392118#10845254, @cscott wrote:

"Extra update MedaiWiki jobs due to Wikifunctions content" will be the mediawiki_refreshlinks_parsercache_operations_total metric with status=cache_miss and has_async_content=true. This the total number of refresh links jobs with async content. If you look at the label async_not_ready=true then these are jobs which are going to need to be repeated once the async content is ready, and so they are "extra" update jobs. In addition, there will be a few extra update jobs with async_not_ready=false when entries fall out of the parser cache, do to the way we currently handle updating async content. So the range of "extra" jobs is between the lower bound of the # of jobs with async_not_ready=true and the upper bound of the # of jobs with has_async_content=true. We can refine this metric further if/when the upper bound gets close to our SLI limit.

Unfortunately, this metric is fixed at 0 right now because we don't use Parsoid to trigger refreshlinks jobs, only legacy parses. Since WF is Parsoid-only at the moment, WF can't affect page metadata and therefore there are currently no extra refreshlinksjobs being created for WF. This will change in the future though (T393716: RefreshLinksJob should use Parsoid-generated metadata).

Re-triggered logstash link looking at https://test.wikipedia.org/wiki/MavetunaTest. The page is filled with Wikifunctions client calls and simple wikitext. Are we accidentally triggering the wrong path here?

Provisional concept of a Q1 epic.

Provisional concept of a Q1 epic.

Problem: The FunctionCallHandler operates on WF.org without context intentionally; passing that along will disrupt the cacheability. To discuss further. Let's discuss further.

We're pretty sure this should work in the back-end, but building the composition in the UX may well be hard/impossible. Did you manage to write such a composition and run into issues (in which case it's a definite bug), or is this more that it seemed/was impossible?

In T365786#10844568, @DSantamaria wrote:

@Jdforrester-WMF Should we close it?

In T392152#10844536, @DSantamaria wrote:

So, should we close it?

To confirm that this is (finally!) fixed.

Needs the pull-throughs to land before it can be deployed.

Specifically, this is about breaking-for-sysadmins changes, I think? New config/new requirements/new behaviour, rather than anything at the code level.

Should now be fixed.

Should now be fixed.

Confirmed also with the code on k8s-mwdebug:

Oh, sorry, I thought we'd already landed all these 8.1 fixes into major extensions' REL1_39 branches.

In T394814#10841481, @Krinkle wrote:

I wouldn't object to that personally.

Long-term that might actually be a viable direction for the extension, to treat the selected backend as a config var / pluggable service class, rather than a separate extension with separate hooks each. Just an idea at this point, there may be various issue with this that I haven't thought through yet :)

In T328921#10836701, @Krinkle wrote:

In T328921#10830122, @Jdforrester-WMF wrote:

In T328921#10829567, @MSantos wrote:

I have a dummy question to ask: once we get the green light from the ServiceOps team to proceed with the deprecation of PHP7.4, what's the effort for the work needed to proceed? Is it possible to measure how many weeks are needed to complete the work?

[…] Your follow-up question below suggests you mean just the actual dropping of active PHP 7.4/8.0 support, which is already done in REL1_44 (like with REL1_43 and REL1_42).

[…] I don't see how this is relevant to the 1.44 release timeline. PHP 7.4 and 8.0 support were dropped in MW 1.42, with a special hack […]

I believe Mateus, by proxy of me, is operating on the assumption that the "backwards cherry-pick" that we applied to MW 1.42 and MW 1.43 (i.e. the dropping of 7.4 and 8.0 support, which is a patch we kind of backported to those two REL branches, but hasn't landed in the master branch yet), is something we prefer not to repeat for the MW 1.44 release.

In T392165#10839292, @DSantamaria wrote:

@Jdforrester-WMF Why is this the parent of a # workstream like "Null Values"?

I believe we have agreed that we are OK to deploy as-is from a code perspective (with changes landed since original deploy).

I believe we have agreed that we are OK to deploy as-is from a process perspective.

It's OKR work, but wasn't tagged as such.

Per Luca.

In T384764#10629639, @gerritbot wrote:

Change #1127075 had a related patch set uploaded (by Reedy; author: Reedy):

[operations/puppet@production] Revert^2 "scap: Port mwgrep to Python 3 and other cleanup"

https://gerrit.wikimedia.org/r/1127075

In T392976#10832927, @Stashbot wrote:

Mentioned in SAL (#wikimedia-operations) [2025-05-18T12:50:21Z] <sbassett> Ran scap remove-patch for T392976

In T328921#10829567, @MSantos wrote:

I have a dummy question to ask: once we get the green light from the ServiceOps team to proceed with the deprecation of PHP7.4, what's the effort for the work needed to proceed? Is it possible to measure how many weeks are needed to complete the work?

In T390753#10823112, @akosiaris wrote:

In T390753#10823059, @akosiaris wrote:

In T390753#10822976, @akosiaris wrote:

Arguably still true, at least per https://trace.wikimedia.org/trace/968783e04dd84f906bdcf24b617cbbc0. Although I think that indeed the rate has dropped.

https://grafana.wikimedia.org/goto/29y0JdaHR?orgId=1 says that no, although those numbers seem wrong (they are off by an order of magnitude?)

Yup, something's off here. Repro:

$ docker-compose restart function-orchestrator 
$ curl -s http://localhost:9100 |grep expr
# HELP express_router_request_duration_seconds request duration handled by router in seconds
# TYPE express_router_request_duration_seconds histogram
$ # So 0 metrics. Now send 100 requests in sequence
$ curl -s -o /dev/null http://localhost:6254/_info?ts={1..100}
$ curl -s http://localhost:9100 |grep expr
express_router_request_duration_seconds_sum{service="function-orchestrator",path="/_info",method="GET",status="200"} 0.013436579999999993
express_router_request_duration_seconds_count{service="function-orchestrator",path="/_info",method="GET",status="200"} 100

When the time for a single request is 1-3 ms, the sum for 100 should be 0.1 to 0.3, not 0.013.

I 'll file this under a separate task though.