We will need to re-file this under Q3's performance epic.

I'm afraid this still fails with v2. Shall we move out to re-triage?

Hmmm. This function is succeeding for population of United States, Germany, England, and Mexico. not currently aware of any failing countries besides Canada. The elapsed time reported for running the United States is under 7 seconds. So I'm wondering if there's something unique about the statement content of the entity for Canada. Would make sense to investigate this question next.

In my local environment, with a longer timeout, the sentence does complete for Canada, but it takes nearly 35 seconds! For the US, it takes under 8 seconds. So yes, it would be interesting to find out why Canada is taking so much longer.

The JSON files, as fetched from the Wikidata LOD API, Have these sizes:

• Q16, Canada: 2051831
• Q30, United States: 2200359

Number of snaks ( by counting occurrences of "snaktype"):

• Q16, Canada: 4305
• Q30, United States: 4269

Number of occurrences of "property": "P1082"

• Q16, Canada: 319
• Q30, United States: 56

Number of occurrences of "property": "P585"

• Q16, Canada: 485
• Q30, United States: 228

Change #1275996 had a related patch set uploaded (by David Martin; author: David Martin):

[operations/deployment-charts@master] Turn on import of references inside Wikidata statements

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

Update: United States, Germany, England, and Mexico observed failing on May 3, 2026, so these failures are intermittent and it's not just Canada that fails.

When I run this with Ecuador, I get a Z579: 32. Looks like we're not configuring the default concurrent call rate limit, and I'm not quite sure why this function tries to make so many concurrent evaluator calls. This error, by the way, is not labelled correctly.

Separately, we get a Z570: 1000 when we try this with Canada.

So, to fix this, we need to

1. increase orchestratorConfig.maxConcurrentEvaluatorCalls to > 32;
2. increase orchestratorConfig.maxSimultaneousExecutions to > 1000 and/or implement tail recursion.

Do we want to do any/all of this?

Separately, I will file a task about the unlabelled error.

Thanks, @cmassaro! We also need to understand why we get Z570: 1000 when we try this with Canada. I believe it's coming from the nested call to Z26700/filter statements in Wikidata item by properties. With Canada and population as inputs, both of the implementations of Z26700 return Z570: 1000. But one of these implementations (Z26702) is a JavaScript implementation, and the other is a composition which does most of its work by calling a code implementation. How is it that a code implementation, iterating over a list, can lead to Z570: 1000 ???

Let's focus on Z26702, as the simpler case. If the code implementation completes, it returns a very small list, so I don't think the Z570 could arise after the implementation completes. Is there some other function call running over the list before invoking the code implementation? Could the error be related to input argument validation or code conversion?

This is now working (with a warning about the MASSIVE Wikidata object we return from the evaluator). Close?