I don't think it's an error in the display function, nor related to Wikidata. This is a familiar issue when the displays are required to run quickly and simultaneously during page rendering.

Try running this function on a string of about 30 characters. Many will fail, especially later on in the list. https://www.wikifunctions.org/view/en/Z22717

Checking on `wikifuncitons wmf.7 - the message "Could not complete due to server error" (504 (Gateway Timeout))

Double-click will result in the "You have too many function calls executing right now." (code: "wikilambda_function_call-concurrency-limit"). Double-clicks are not prevented?

This is a familiar issue when the displays are required to run quickly and simultaneously during page rendering.

That's totally right. In this case, there are 54 display functions being sent to the orchestrator at the same time, so they all fail with a concurrency limit error:

{
    "error": {
        "code": "wikilambda_function_call-concurrency-limit",
        "info": "You have too many function calls executing right now.",
        "docref": "See https://www.wikifunctions.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."
    },
    "servedby": "mw-wikifunctions.codfw.group1-5975896df4-q5p6p"
}

There's few things that I think need to be solved here:

• The state should not remain as "Running..."
• In view mode (which is the case of function call outputs), display functions are just called once. However, whenever they returned error, they are not re-run. We should probably change this, and re-run if they failed the first time.
• We should handle display functions in a queue, and send them to the orchestrator safely one by one.

Change #1191727 had a related patch set uploaded (by Genoveva Galarza; author: Genoveva Galarza):

[mediawiki/extensions/WikiLambda@master] Mark rendered value as initialized only when succesfully initialized

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

Change #1191727 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] Mark rendered value as initialized only when succesfully initialized

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

Change #1192181 had a related patch set uploaded (by Genoveva Galarza; author: Genoveva Galarza):

[mediawiki/extensions/WikiLambda@master] [WIP] Create job queue store module for scheduling accummulative parser/renderer calls

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

Change #1192181 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] Create job queue store module for scheduling parser/renderer calls

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

In T397542#11213791, @gengh wrote:

There's few things that I think need to be solved here:

• The state should not remain as "Running..."
• In view mode (which is the case of function call outputs), display functions are just called once. However, whenever they returned error, they are not re-run. We should probably change this, and re-run if they failed the first time.
• We should handle display functions in a queue, and send them to the orchestrator safely one by one.

The 1st one I see it will fallback to the name and the sub values, for example: ' (Day of Roman year (March, 21)' instead of 'March 21'
The 2nd one should be addressed here: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/1208367 and
The 3rd: we are using enqueue there but I am not sure if thats enough for the queueing .

One suggestion I would have is to delay renderers/display functions untill they are inview
@gengh What do you think?

In T397542#10936478, @99of9 wrote:

Try running this function on a string of about 30 characters. Many will fail, especially later on in the list. https://www.wikifunctions.org/view/en/Z22717

I just tried this again, and the current behaviour looks almost ideal. They all start as "running", then one by one they render. None of them fail. The only two possible improvements I could imagine are: generally rendering faster, or going back to running more/all in parallel but not erroring any that are just still queued. But again, I think the current behaviour is close to optimal, so focus would be better applied to other things.

The concurrency errors given by the stampede of renderer function calls at once is fixed.
Thanks @99of9, I'll be closing this task now.